Sites blokkeerden Internet Explorer door bug in statistieksoftware

Gedurende korte tijd dit weekend konden gebruikers van Internet Explorer een groot aantal sites niet bezoeken. Boosdoener was een fout in de code van het statistiekprogramma Sitemeter.

In de nacht van vrijdag op zaterdag waren websites die de statisitiek- en analysetool Sitemeter gebruiken om informatie over hun bezoekers te verzamelen onbereikbaar voor Internet Explorer-gebruikers. Wie de sites probeerde te bezoeken met Microsofts browser kreeg slechts een melding te zien dat de site niet geopend kon worden. Sitemeter wordt door een groot aantal websites gebruikt, waaronder vrijwel alle online titels van Gawker Media, eigenaar van onder meer Gizmodo, Lifehacker, Kotaku en Jalopnik. Ook bekende sites als Perez Hilton werden getroffen door de bug.

Nader onderzoek wees uit dat Sitemeter een oude bug van Internet Explorer 6 en 7 over het hoofd gezien had. Sitemeter heeft de fouten inmiddels achterhaald en opgelost. Gebruikers van IE6 en 7 kunnen van Sitemeter-code voorziene sites weer bezoeken en eigenaars van internetpagina's die de statistieksoftware uitgeschakeld hadden, kunnen deze weer inschakelen. Oorzaak bleek een fout in de manier waarop Internet Explorer scripts verwerkt: de technici van Sitemeter hadden na een update van hun code geen rekening met deze oude bug gehouden. Overigens hadden andere browsers, zoals Opera en Safari, geen last van de fout in de code.

Reacties (47)

[Rhino]

Is de titel dan niet vreemd?

"Sites blokkeerden Internet Explorer door bug in statistieksoftware"

... terwijl het eigenlijk om een (bekende) bug in IE gaat waar Sitemeter geen rekening mee had gehouden.

[SinergyX]

IE blokkeerde toch niet, maar stopte toch gewoon met werken?

Oftewel:
Sites onbereikbaar met IE door bug in statistieksoftware.

[zenlord]

Eigenlijk zit de bug in IE, niet in de statistiek-software, dus misschien nog even aanpassen...

[Cameleon73]

Eigenlijk had de titel dan ook "Internet Explorer blokkeerde sites door bug in statistieksoftware" moeten zijn.

[kzin]

Misschien "Internet Explorer blokkerde sites door bug in Internet Explorer" ??

Als het script per ongeluk geen rekening houdt met een bug in IE, waar ligt dan de root-cause?

Het is mooi als je om fouten van anderen heen weet te programmeren, maar als je dat een keer niet doet, waar zit de fout dan?

Als ze bij de supermarkt altijd krentenbrood en rozijnenbrood door elkaar gooien, en ik weet dat, maar bestel toch een keer rozijnenbrood als ik rozijnenbrood wil hebben, heb ik het dan fout gedaan?

[_Quinten_]

Testen die hun code niet voor ze deze gebruiken?

[MaZeS]

Dat je bij een specifieke situatie/website iets over het hoofd ziet oké, maar als de fout inderdaad op ALLE websites met sitemeter optrad geeft dat inderdaad aan dat er wel heel belabberd is getest...

[Patriot]

Ehm, het zou niet logisch zijn als een dergelijke fout zich slechts op enkele websites voor zou doen. Sitemeter werkt voor zover ik weet gewoon met een javascriptbestand op een server van Sitemeter. Alle websites die gebruik maken van Sitemeter maken dus gebruik van het zelfde javascript bestand.

[kzin]

Ik denk met javascript in je browser. Als je brower een fout tegenkomt bij het uitvoeren van het script, en de fout wordt niet goed afgevangen, dan kan het maar zo zijn dat de rest van de pagina niet meer wordt weergegeven.

[Freee!!]

Maar je browser laadt dat Javascript in vanaf de Sitemeter server (onafhankelijk van de bezochte pagina/site).

[zenlord]

Ik vind het niet verkeerd om te testen met de meest courante, *gepatchte* browsers. Blijkbaar werkt de statistieksoftware wel als de 'oude bug in bepaalde IE-versies' gepatcht is of er een workaround voor verspreid is. Als je software niet werkt in IE 6, dan heb je slecht getest. Als je software wel werkt in IE 6.0.158r3 (bvb) en alle latere versies, maar niet in versie 6.0.158r2, dan kan je toch moeilijk een workaround in jouw prog gaan voorzien voor deze bug? Gegarandeerd zijn er nog dergelijke bugs, waarvoor je dan allemaal workarounds moet gaan verzinnen.

Vereis dan gewoon dat de browser van de bezoeker up to date is - je helpt er de rest van de internetgebruikers tegelijkertijd ook nog eens mee, want met een niet-gepatchte browser vorm je potentieel een gevaar.

[Mortis__Rigor]

Datzelfde kun je natuurlijk zeggen over IE. Het is een bug die al bestaat vanaf versie 5.5. Waarom hebben ze die dan niet gefixed? Een workaround maken rond een bug is de-facto de verkeerde oplossing.

edit:
Ik kan natuurlijk geen bug in IE fixen. De developpers bij Microsoft volgens mij wel, en zeker als de fout er al zo lang inzit.
Als er in code van mij een bug zit, zal de klant tijdelijk kunnen leven met een workaround, maar zal die toch eisen dat het opgelost wordt.

[Reactie gewijzigd door Mortis__Rigor op 23 juli 2024 10:17]

[Woet]

Komt door die idiote DOM loading die IE heeft.. je mag geen elementen aanroepen met javascript, maar dat moet allemaal in timeouts en onload's.

[Niemand_Anders]

Javascript hoort niet in de body thuis! In elk boek over javascript wordt aangeraden om javascript in de header te plaatsen. En als je in de knowlegdebase van Microsoft kijk, vind ik deze 'bug' nog nieteens zo vreemd. Hij is zelfs vrij logisch.

Aangezien je het schript overschrijft door iets anders. Het script is 'in gebruik' en kan dus niet overschreven (geopend) worden.

Heeft helemaal niets met onloads en timeout's te maken en ik vraag me dan ook af of je wel de moeite hebt genomen om naar de workaround te kijken.

[arendjr]

Javascript hoort niet in de body thuis! In elk boek over javascript wordt aangeraden om javascript in de header te plaatsen.

Realiseer je wel dat er een verschil zit tussen theorie en praktijk, en dat er in de praktijk soms toch situaties zijn waarbij je wel code in de body moet zetten.

En als je in de knowlegdebase van Microsoft kijk, vind ik deze 'bug' nog nieteens zo vreemd. Hij is zelfs vrij logisch.

Zo logisch dat je je bijna zou afvragen waarom andere browsermakers niet op het idee zijn gekomen om deze bug te implementeren.

Aangezien je het schript overschrijft door iets anders. Het script is 'in gebruik' en kan dus niet overschreven (geopend) worden.

Dat slaat natuurlijk helemaal nergens op. Een script dat in de DOM staat wordt gevoerd aan de JS interpreter, en kan vanaf dat moment prima overschreven worden. Of dacht je dat de JS interpreter voor ieder statement opnieuw de DOM ging uitlezen? Nou ja, misschien bij IE dus wel...

[g4wx3]

Javascript hoort net zo min in de body als css. Voor een klein dingetje dat eenmalig voorkomt vin ik het niet zo erg.
Anders moet je gewoon de juiste methoden gebruiken:
<script type="text/javascript" src="shared/javascripts.js">
<body onload="start()">

En in dat afzonderlijk bestand staat al je javascript. Op die manier kan het ook gecashed worden, en bespaar je bandbreedte.

unubstructive javacript....

[MBV]

CSS mag niet volgens de standaard, Javascript wel. Check de DTD maar:
[code]<!ENTITY % head.misc "SCRIPT|STYLE|META|LINK|OBJECT" -- repeatable head elements -->
...
<!ENTITY % special
"A | IMG | OBJECT | BR | SCRIPT | MAP | Q | SUB | SUP | SPAN | BDO">
[/code]
Op de plek van een A-tag mag je dus ook een SCRIPT-tag neerzetten, maar geen STYLE-tag. Dus CSS hoort niet in de body, javascript mag wel.

[Little Penguin]

Javascript hoort niet in de body thuis! In elk boek over javascript wordt aangeraden om javascript in de header te plaatsen

Erg gek dat ik dan ook regelmatig adviezen lees die juist aanraden om de JavaScript helemaal aan het eind van de pagina te plaatsen.

Verder vind ik het opvallend dat 1 van de workarrounds het gebruiken van de W3C-DOM is ipv de IE-originated innerHTML

Hopenlijk dat de Acid-testen helpen tegen dit soort inconsistenties tussen browsers - en dat MS natuurlijk in het vervolg wat actiever is in het oplossen van bugs...

[ShellGhost]

Alsof de Acid test zo heilig is.
Men hoeft dus bv alleen maar een plaatje goed te renderen en jij bent overtuigd dat het een goede degelijke browser is?

[crazyx]

Het is in ieder geval al een begin. Maar voor IE is zelfs het begin nog moeilijk.

[Little Penguin]

Alsof de Acid test zo heilig is.

Nee, dat is hij niet - maar de Acid2 en 3 testen hebben wel degelijk een aantal testen voor dit soort edge-cases. (Waarbij er dus getest wordt op gedrag inzake foutieve invoer)

Men hoeft dus bv alleen maar een plaatje goed te renderen en jij bent overtuigd dat het een goede degelijke browser is?

Nee, absoluut niet. Maar die testen zorgen er wel voor dat de browserfabrikanten betere ondersteuning hebben voor diverse standaardzaken...

[Edwinboss]

er is geen enkele browser die problemen heeft met javascript in de body-tags
alleen moet je wel weten wat je doet want javascript in de body wordt uitgevoerd zodra het gelezen is
dus niet meteen bijvoorbeeld elementen gaan aanroepen die mogelijk nog niet eens bestaan omdat ze zich onder het stukje script bevinden

[Isnowiz]

Snap niet dat je je site afhankelijk maakt van zo'n 3rd party...

[Rixard]

Waarom zelf een statistiekentool ontwikkelen als er al zat op de markt zijn? Dit had natuurlijk voorkomen kunnen worden door goed te testen.

[Hydra]

Er zit een fout in IE waar ze geen rekening mee gehouden hebben. IE stop gewoon met werken als 'ie een bepaald stuk JavaScript tegen komt, iets wat niet zou moeten gebeuren. Het is dus een combinatie van een bug in IE en niet goed testen.

[killingdjef]

4 jaar geleden stond testen in de kinderschoenen... blijkbaar is er niet veel veranderd

[hamsteg]

4 jaar geleden? Sinds de eerste regels code waarbij een conditie om de hoek kwam kijken is dit al een ondergeschoven kindje. Programmeurs zijn van nature alleen maar positief ingesteld, die uitdaging heeft elk bedrijf om een paar zuurpruimen te vinden die echt goed kunnen testen. Deze mensen zijn vaak niet geliefd ... helaas.

[humbug]

Zuurpruimen niet nee, mensen die en goed kunnen testen en ook nog kunnen aangeven hoe het gereproduceerd moet worden en dit ook nog een beetje tactisch naar een ontwikkel team kunnen overbrengen worden over het algemeen wel gewaardeerd.

De meeste ontwikkelaars zien het nut van goede testers ondertussen wel. Niet allemaal, maar dat zijn meestal ook ontwikkelaars die slecht kunnen programmeren.

[arendjr]

Natuurlijk is het slordig van Sitemeter dat ze dit kennelijk live hebben gegooid zonder goed te testen, maar tegelijk geeft het wel goed aan waarom veel ontwikkelaars zo'n gruwelijke hekel hebben aan Internet Explorer.
In een normale markt zou een browser met zo veel bugs (want dit is bij lange na niet het enige probleem met IE) nooit een fatsoenlijk marktaandeel kunnen houden en vanzelf irrelevant worden. In plaats daarvan blijven veel gebruikers toch op IE zitten en moet de rest van de wereld z'n software/websites daar maar op aanpassen.
Gelukkig gaat het nog steeds, zij het heel langzaam, de goeie kant op...

[ritsjoena]

Zelfs met heel goed testen kan er altijd iets tussendoor glippen. Met name van dit soort rare dingen die niet eens zouden moeten kunnen. (als MS z'n fouten jaren geleden al had opgelost).

Wat dat betreft is het belangrijker te kijken naar hoe en hoe snel ze het hebben opgelost. Wat dat betreft vind ik het netjes, binnen een paar dagen inclusief weekend.

Ik neem aan dat dit probleem voortaan op hun checklist zal staan.

[stefanos1990]

Heel goed testen?
Er tussendoor glippen?

Ze hebben gewoon niet getest op de twee meeste gebruikte browsers die er zijn (IE 6 + 7), dat is geen tussendoor glippen meer,

Ze hebben het misschien snel opgelost, maar iets dat zo'n grote fout veroorzaakt bij 70% van de internet gebruikers had helemaal niet online mogen gaan.

Btw, gewoon Firefox gebruiken mensen

[Little Penguin]

Heel goed testen?
Er tussendoor glippen?

Het is heel goed mogelijk dat het helemaal nog niet de bedoeling dat deze code ook daadwerkelijk op een publieke server geplaatst zou worden. Misschien dat een overijverige programmeur/manager de code op de productieserver gezet heeft.

Ze hebben gewoon niet getest op de twee meeste gebruikte browsers die er zijn (IE 6 + 7), dat is geen tussendoor glippen meer,

Om te beginnen heb je gelijk, 50-70% van de potentiele gebruikers buitensluiten is niet erg slim, maar het kan dus een vergissing geweest zijn (zie mijn eerdere opmerking in deze reactie).

Verder geeft het te denken over de gebruiksvriendelijkheid van IE voor een webontwikkelaar als er blijkbaar door bijna niemand (meer) op ontwikkeld wordt?

Ze hebben het misschien snel opgelost, maar iets dat zo'n grote fout veroorzaakt bij 70% van de internet gebruikers had helemaal niet online mogen gaan.

Tsja, je mag ook niet harder dan 120 op de Nederlandse snelwegen.

Btw, gewoon Firefox gebruiken mensen

Get Mozilla Firefox browser

[ronny]

Het is maar hoe je het bekijkt.
Uit de statestieken is gebleken dat alle bezoekers zijn overgestapt op alternative browsers en het aandeel IE is gedaalt tot 0%.
Hierdoor nemen de ontwikkelaars niet meer de moeite om rond de bugs van IE te werken.

[crisp]

Overigens aardig om te vermelden dat IE8 de betreffende bug ook nog steeds heeft, maar dat in plaats van de gewraakte melding 'operation aborted' nu gewoon de javascript uitvoering stilletjes wordt gestaakt

[buzzin]

Dus doordat er een bug in IE zit krijgt sitemeter op z'n kop?
Ze hadden de bug natuurlijk ook gewoon bij MS kunnen oplossen......
Maar het is typisch voor IE dat de website ontwikkelaars maar om de bugs van IE heen moeten werken....