Alt-I, des informations alternatives - Informatique, Cultures alternatives et Geekeries saupoudrées d'Ajax. - IE SUX

IE8 VS FX2 VS SF3

Hadrien — Fri, 07 Mar 2008 16:04:00 +0100

Derrière ce titre au nom barbare se cache un test comparant Internet Explorer 8 ßeta 1, Firefox 2 et Safari 3. Le test est simple. Chacun des 3 navigateurs sont dans la même machine virtuelle, elle même tournant sur un MacPro BiXeon dual core 2,66Ghz et 3Go de RAM. Les 3 navigateurs ont chargé la page http://www.hadrien.eu. Elle est donc en cache. Seule les performances sur l'éxecution du javascript (très lourd dans le cas de ma page) comptent. Rigolons :

Internet Explorer 8 : la bouse
envoyé par hadrienl

Lien direct vers la vidéo en mp4

Comme on peut le constater, IE8 rame comme une merde, Firefox est pas mal du tout, et Safari 3 déchire tout.

Acid test 3

Hadrien — Thu, 14 Feb 2008 10:51:00 +0100

On va encore se marrer. L'Acid test version 3 a été testé sur tout les navigateurs du marché. Voici ce qui devrait s'afficher sur un navigateur respectant les standards à 100% :

Malheureusement, on est loin du compte. Seule la dernière nightbuild de WebKit atteind un score respectable de 82% :

Et marrons nous devant IE6 et IE7 :

Voilà, avec 70% de navigateurs qui n'arrive même pas à 15% d'un test de standards, le web est mal barré…

À la recherche du bug perdu

Hadrien — Wed, 06 Feb 2008 17:14:00 +0100

Je viens de terminer un safari du bug IE6 assez incroyable. Le bug en question se produisait lorsqu'on arrivait sur le control panel d'over-blog (la page d'accueil de l'admin), sous Internet Explorer, avec certains blogs en particulier. La conséquence était un freeze du ~~bouzin~~ navigateur. Le principal suspect était l'applet flash qui affiche les statistiques.

Après avoir enfin trouvé un blog en dev confronté au problème, nous avons pu faire des tests poussés. Tout d'abord, désactivation de l'applet flash. Toujours le plantage. Hm… ce n'est donc pas Flash qui est cause.
J'enchaîne en désactivant tout le control panel. Plus de soucis. Il s'agit bien d'une zone du tableau de bord : le module "Promo Premium et PDA". En désactivant petit à petit chaque partie du HTML de ce template, on en arrive à trouver la cause du problème. Un <br /> :|

<ul>
	{if empty($thematics)}
	<li>
		<br />{$lg->getText('message.thematicNotSelected')}
	</li>
	{/if}
</ul>

C'est ce <br /> (ne me demandez pas ce qu'il fait là) qui faisait planter IE ! Je trouve ça très fort.

Les styles de IE

Hadrien — Tue, 15 Jan 2008 16:15:00 +0100

Pour patienter devant cette attente insurmontable, une petite blague dans la catégorie IE SUX. Voici les styles que IE applique à toute page web avant de la charger :

* html {
	word-wrap: break-word;
	explorer-stability: random ;
	mso-random-crap: true;
	mso-more-unnecessary-wankery: 15;
	mso-non-standard-selector: naturally;
}

Requêtes Ajax et Internet Explorer

Hadrien — Fri, 04 Jan 2008 12:05:00 +0100

J'inaugure une nouvelle catégorie "IE SUX" dans laquelle j'exprimerais mes coup de gueules envers les malfonctions de cette bouse infâme qu'est Internet Explorer. Aujourd'hui, IE et les requêtes Ajax.

Un bug sur Over-blog : impossible de mettre un caractère accentué à un nom de catégorie sous IE. Celui-ci envoie systématiquement le string en ISO au lieu d'UTF-8.

Après moulte fouilles et tentatives de debug, j'ai finalement trouvé la cause du problème. Il s'agit en fait d'un bug de l'objet ActiveX XMLHTTP de IE (6 et 7). Lorsque l'on envoie des données via une requête Ajax en Get, IE se fait un malin plaisir à envoyer la donnée en tant que UTF-8, mais en réalité en ISO. D'où la réception d'un caractère foireux. Par contre, si les données sont envoyées en Post, aucun problème, c'est de l'UTF-8 qu'il envoit.

Conclusion, envoyez toute vos requêtes Ajax en Post. Merci Microsoft.