- Safari et Firefox déploient du code qui modifie le rendu et le comportement des API sur certains domaines comme TikTok, Netflix ou Instagram
- about:compat dans Firefox affiche les interventions par site et leurs interrupteurs, avec injection de CSS et de JavaScript sur mesure ainsi que camouflage de l’agent utilisateur
- WebKit dans Safari gère cela sous forme de quirks, en contournant domaine par domaine des problèmes liés aux vidéos PiP, à l’alignement d’images, aux popovers et à l’accès au streaming
- Chrome a très peu besoin de fichiers d’exceptions séparés, car le web est déjà construit de manière centrée sur Chrome, et les autres navigateurs compensent les écarts
- Comme ces exceptions apparaissent rarement dans les logs ou la console, les développeurs devraient tester régulièrement dans Firefox et Safari et vérifier s’ils figurent dans des fichiers de quirks
Gestion des exceptions par domaine dans les navigateurs
- Safari et Firefox déploient du code qui modifie le rendu ou le comportement des API selon le domaine visité par l’utilisateur
- Des sites comme TikTok, Netflix, Instagram ou SeatGuru font partie de ces traitements spécifiques par site
- Les sources associées sont consultables publiquement dans
Quirks.cpp de WebKit et dans les interventions WebCompat de Firefox
- Ce code est intégré au moteur de rendu du navigateur sous la forme de règles du type « si c’est un domaine précis, rendre différemment » ou « si c’est un domaine précis, traiter autrement les appels d’API »
- Chrome n’a pratiquement pas besoin de fichiers d’exceptions de ce type, ce qui met en évidence une asymétrie : le web est déjà construit autour de Chrome
about:compat dans Firefox
- En saisissant
about:compat dans la barre d’adresse de Firefox, on peut voir la liste des interventions par site et leurs interrupteurs
- Chaque entrée correspond à une correction sur mesure pour un site web particulier, et la désactiver permet de constater que le site se casse
- Le système WebCompat de Firefox injecte du CSS et du JavaScript adaptés à des domaines précis
- Pour les sites qui identifient mal le navigateur, Firefox modifie la chaîne de l’agent utilisateur qu’il leur envoie
- Ces interventions masquent les bugs pour éviter que le web paraisse cassé, et Mozilla Bugzilla permet de suivre jusqu’aux rapports de bug et tentatives de contact avec les sites
Les quirks de Safari
- Le moteur WebKit de Safari appelle ce type de traitement des quirks, et
Quirks.cpp est publié sur GitHub
- Le code de WebKit contient un commentaire indiquant que Facebook, X et Reddit mettent en pause les
<video> qui ont défilé hors de l’écran, qu’ils soient ou non en mode PiP
- Safari détecte
facebook.com, x.com et reddit.com et modifie le traitement des vidéos Picture-in-Picture
- Même si le code vidéo du site est cassé, le navigateur déploie un contournement pour tous les utilisateurs sans attendre que l’entreprise concernée corrige son site
- Un commentaire lié à SeatGuru indique
FIXME: Remove this quirk if seatguru decides to adjust their site., ce qui montre que l’exception peut être retirée si le site est corrigé
- L’historique des commits montre plusieurs corrections spécifiques à des sites au cours des derniers mois
- problème d’image de plan d’étage Zillow qui ne se centre pas
- problème d’affichage du message « please upgrade your browser » sur TikTok
- problème de redimensionnement irrégulier pendant la lecture des Instagram Reels
- problème où le bouton « Episodes and Info » de Netflix ferme incorrectement un popover
- problème où Twitch met en pause la vidéo PiP lors d’un changement d’onglet
- problème où Amazon Prime Video n’autorisait pas la lecture pour les utilisateurs de Safari
Le web centré sur Chrome et son asymétrie
- Les quirks de WebKit et WebCompat dans Firefox ne se contentent pas de réparer des sites cassés : ils compensent aussi une situation où Chrome définit de fait ce que signifie « ça fonctionne »
- En général, quand Chrome déploie une fonctionnalité, sa domination du marché pousse les développeurs à l’utiliser, puis les autres navigateurs doivent soit implémenter cette fonctionnalité, soit masquer les différences via des exceptions spécifiques à des sites
- Au moment où Safari et Firefox rattrapent leur retard, les contournements ont déjà été déployés auprès de millions d’utilisateurs
- WebKit inclut des surcharges d’agent utilisateur qui font passer Safari pour Chrome sur les pages vidéo d’Amazon et plusieurs services de streaming
- Comme ces sites détectent la présence de Chrome et offrent une expérience dégradée aux autres navigateurs, WebKit trompe sur l’identité de Safari pour protéger ses utilisateurs
Quirks.cpp contient actuellement la fausse chaîne d’agent utilisateur Chrome suivante
auto chromeUserAgent = "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36"_s;
- Firefox fonctionne de la même manière, et de nombreuses interventions visibles dans
about:compat consistent à faire croire au site : « je suis Chrome » via un camouflage de l’agent utilisateur
- Le wiki Mozilla précise que certains sites « bloquent complètement l’accès, affichent un design différent ou fournissent des fonctionnalités différentes » selon le résultat de la détection du navigateur
- Cette structure crée une boucle de rétroaction
- les développeurs prennent Chrome comme référence parce que sa part de marché est élevée
- les sites fonctionnent le mieux dans Chrome
- les utilisateurs qui rencontrent des bugs dans d’autres navigateurs accusent le navigateur plutôt que le site
- les utilisateurs migrent vers Chrome, ce qui renforce encore sa domination
- Si Chrome n’a presque pas besoin de fichier de quirks séparé, ce n’est pas tant parce qu’il serait mieux conçu que parce que le web est déjà adapté à Chrome
- Dans une situation où les navigateurs basés sur Chromium dépassent 80 % d’usage, les développeurs ciblent d’abord Chrome
- Si un site fonctionne dans Chrome, il est mis en production, et s’il casse dans Safari ou Firefox, le problème devient moins prioritaire
- Chrome ne se contente pas d’ajouter des exceptions : il fixe l’agenda
- Quand Chrome modifie un comportement, les sites se mettent à jour en conséquence, et les autres navigateurs doivent suivre ou casser
L’écart entre les spécifications et le web réel
- Les ingénieurs navigateurs peuvent considérer que les spécifications actuelles sont bien définies et que l’approche de « living specification » d’HTML5 a réduit le chaos de l’époque IE/Netscape
- Le problème est que les développeurs s’appuient sur des détails d’implémentation qui ne figurent pas dans les spécifications, puis accusent les navigateurs non conformes lorsque ces détails diffèrent ailleurs
- Si l’implémentation de Chrome devient la référence visée par tous, alors ses comportements détaillés hors spécification deviennent la spécification de fait
- À l’époque d’Internet Explorer dans les années 2000, les développeurs construisaient déjà les sites pour IE, ce qui cassait les autres navigateurs et faisait passer « fonctionne dans IE » avant la conformité aux standards
- On espérait autrefois qu’un meilleur respect des standards web ferait disparaître les quirks des navigateurs, mais en pratique ils n’ont pas disparu : ils se sont simplement déplacés vers les navigateurs qui ne sont pas Chrome
- Les standards existaient pour éliminer le code spécifique à chaque navigateur, mais après être sortis de l’ère IE, le web a recréé le même problème autour d’autres navigateurs
- Désormais, le code spécifique à un navigateur ne se trouve plus dans le navigateur dominant, mais dans les navigateurs non dominants qui compensent un web conçu pour le navigateur dominant
Le traitement des exceptions est plus profond qu’on ne le pense
- Ce traitement ne se limite pas à des ajustements visuels : il modifie le comportement de base du navigateur selon le domaine
- Rien que la liste de WebKit s’étend sur des milliers de lignes et couvre le comportement de défilement, la gestion des événements tactiles, le calcul du viewport et même le traitement des types MIME d’images
- Un commentaire sur la fonction de zoom des images produit d’Amazon contient le passage suivant
When panning on an Amazon product image, we’re either touching on the #magnifierLens element or its previous sibling.
- Après avoir vérifié qu’il s’agit bien d’Amazon, Safari modifie sa façon de convertir des événements tactiles en événements souris pour la fonction de zoom produit
- Comme le site d’Amazon suppose un comportement d’événement particulier différent du comportement par défaut de Safari, Safari fournit ce comportement uniquement pour Amazon
- Il existe aussi des quirks par domaine pour le storage access, le rendu des barres de défilement, le comportement d’autocorrection et la gestion du zoom
- Chaque exception est placée derrière un test de domaine et compilée dans l’exécutable du navigateur
Pourquoi les navigateurs corrigent directement plutôt que d’attendre
- Il arrive que les éditeurs de navigateurs contactent les sites concernés pour demander une correction, et le code source contient même des champs avec des liens vers les efforts d’outreach
- Mais lorsqu’un site populaire fonctionne dans Chrome et casse dans leur propre navigateur, les utilisateurs accusent le navigateur, pas le site
- Du point de vue du navigateur, il est plus pratique de déployer dès le lendemain un contournement de cinq lignes que de soumettre un bug à un tiers puis d’attendre des semaines ou des mois
- Il n’est d’ailleurs pas toujours clair qui contacter
- le développeur qui a écrit le code cassé a peut-être déjà quitté l’entreprise
- l’équipe propriétaire de ce endpoint peut ne pas se sentir responsable
- le site peut être en mode maintenance avec seulement des correctifs de sécurité
- Pour le navigateur, le choix le plus simple est de corriger immédiatement et discrètement afin de réduire les problèmes des utilisateurs
- Un ingénieur WebKit a aussi publié un billet sur le processus de suppression d’un quirk pour FlightAware
- FlightAware comparait des chaînes de matrice de transformation CSS, puis un changement de la spécification CSS sur la sérialisation des valeurs a cassé le site quand le navigateur a respecté la spécification
- Les ingénieurs ont ajouté du code spécifique au domaine vérifiant
flightaware.com, puis le contact a fini par aboutir, FlightAware a corrigé son code et le quirk a été supprimé
- Pendant ces quelques mois, les utilisateurs de Safari ont bénéficié d’une expérience correcte grâce à un
if dans le navigateur
Ce que les développeurs doivent vérifier
- Il est possible qu’un site web bénéficie à son insu d’un traitement de rendu spécial
- Ce type de quirk n’apparaît ni dans les journaux d’erreurs ni dans la console avec un avertissement du type « le navigateur contourne une erreur »
- Les contournements sont conçus pour rester invisibles
- Les sites testés principalement dans Chrome sont particulièrement à risque
- Si un site semble fonctionner parfaitement, ce n’est peut-être pas grâce à un bon code, mais parce que le comportement de Chrome correspond par hasard aux hypothèses du développeur
- Les autres navigateurs se retrouvent alors à devoir choisir entre montrer le site cassé aux utilisateurs ou l’ajouter à leurs fichiers de quirks
- Il faut ouvrir son site dans Firefox et Safari non pas occasionnellement, mais régulièrement
- Les fichiers de quirks existent précisément parce que les développeurs ne le font pas de façon régulière
- Si votre domaine figure dans un fichier de quirks, il faut examiner ce que le navigateur contourne
- Le web a continué à fonctionner sans intervention des développeurs, mais il se peut que des ingénieurs d’un navigateur que vous n’utilisez pas aient résolu à votre place des problèmes dont vous n’aviez même pas connaissance
1 commentaires
Avis sur Lobste.rs
Il y a une discussion intéressante cachée derrière le blabla LLM
On peut ne pas aimer le style, et je n’ai pas spécialement envie d’en débattre, mais un mauvais texte ne veut pas forcément dire qu’il a été écrit par une IA. Il y avait déjà plein de phrases médiocres avant l’IA
C’est regrettable, et j’aimerais vivre dans un monde où Google n’influence pas autant le Web de cette façon. Le rêve du « Web » était bien plus ambitieux et, personnellement, inspirant ; c’est dommage d’en être arrivé là
Les blocs de citation sont difficiles à lire. C’est peut-être un problème de mode sombre
Cela dit, le partage des détails sur le contournement était utile
Le passage « Ces sites détectent si c’est Chrome et offrent une expérience dégradée aux autres navigateurs. Donc, au lieu de laisser les utilisateurs de Safari en baver, WebKit ment sur son identité » semble être quelque chose qui se répète dans toute l’industrie
Les fabricants d’ordinateurs publient aussi assez souvent des firmwares ACPI qui cachent des informations aux systèmes d’exploitation non pris en charge, et cela finit par pousser ces OS à se faire passer pour Windows afin de tromper le firmware
Je n’aime pas le fait que ce texte se lise comme un style d’écriture IA
Il y a aussi deux boucles de rétroaction en plus de celles mentionnées ici. La première, c’est que Chrome domine, donc les développeurs construisent pour Chrome ; du coup, tout marche mieux sur Chrome ; et quand ça casse ailleurs, les utilisateurs accusent le navigateur plutôt que le site, puis migrent vers Chrome
La seconde, c’est quand un site est cassé sur Firefox, mais que l’exploitant du site affirme ne voir aucun utilisateur Firefox dans ses statistiques. Cela peut arriver même avec des traitements spéciaux comme la modification du user agent
Si je me souviens bien, le Opera classique (Presto) a été le premier à commencer à implémenter ce type de couche de compatibilité
Le fait que l’implémentation devienne la spécification est un problème répandu dans ce domaine. Dans mon ancien travail, nous utilisions un langage de workflow avec des tests de conformité en espérant voir apparaître plusieurs implémentations et rendre les workflows portables
Le problème central, c’est qu’il y a peu d’incitations économiques à rendre cette portabilité totale. On a envie d’ajouter des fonctionnalités spécifiques à sa propre implémentation pour que les gens restent sur son produit
Et puis on n’a pas le temps de construire du logiciel en mode comité, donc on veut implémenter les nouvelles fonctionnalités en avance
L’implémentation devient la spécification parce que nous vivons dans une société humaine
Ce n’est pas nouveau. Les navigateurs minoritaires ont toujours embarqué des hacks pour certains sites, et autrefois la cible, c’était IE. L’alternative, c’était juste de laisser les sites cassés
Il y a des décennies, les développeurs Web construisaient des sites qui ne fonctionnaient que sur IE et disaient « utilisez IE si vous voulez utiliser ce site » ; aujourd’hui, la même chose se répète avec Chrome. Que Chrome ait raison ou tort n’a pas d’importance. Le site ne fonctionne que sur Chrome, et si les autres navigateurs ne garantissent pas sur ce site le même comportement que Chrome, les gens disent « ce navigateur est cassé » et passent à Chrome
Ce que je me demande vraiment, c’est si les gens pensent que Gecko et WebKit devraient laisser ces sites cassés au nom des principes, ou s’ils pensent simplement que tout le monde devrait utiliser Chrome et aucun autre navigateur. En dehors des hacks spécifiques à certains sites, il n’y a que ces deux options
Je trouve drôle que Firefox et Safari se fassent passer pour Chrome via leur user agent
Cela dit, la chaîne de user agent de Chrome garde elle-même des traces fossilisées de l’époque où il se faisait passer pour un navigateur Mozilla et un navigateur Apple
Il y a des strates géologiques entières dans cette seule ligne de code :