- Safari und Firefox liefern Code aus, der Rendering und API-Verhalten auf bestimmten Domains wie TikTok, Netflix und Instagram verändert
- about:compat in Firefox zeigt site-spezifische Eingriffe und Schalter an und führt benutzerdefinierte CSS-/JavaScript-Injektionen sowie User-Agent-Tarnung aus
- WebKit in Safari verwaltet dies als Quirks und umgeht domain-spezifisch Probleme bei PiP-Videos, Bildausrichtung, Popovers und Streaming-Zugriff
- Chrome braucht kaum separate Ausnahmedateien, weil das Web bereits Chrome-zentriert gebaut ist und andere Browser die Unterschiede ausgleichen
- Diese Ausnahmen tauchen in Logs oder der Konsole kaum auf, daher sollten Entwickler regelmäßig in Firefox und Safari testen und prüfen, ob ihre Seite in einer Quirks-Datei enthalten ist
Domain-spezifische Ausnahmebehandlung im Browser
- Safari und Firefox liefern Code aus, der je nach vom Nutzer besuchter Domain Rendering oder API-Verhalten verändert
- Websites wie TikTok, Netflix, Instagram und SeatGuru sind Ziel solcher site-spezifischen Behandlungen
- Der zugehörige Quellcode lässt sich öffentlich in WebKits
Quirks.cpp und in den WebCompat interventions von Firefox einsehen
- Dieser Code ist direkt in die Rendering-Engine des Browsers eingebaut und folgt Mustern wie „auf einer bestimmten Domain anders rendern“ oder „auf einer bestimmten Domain API-Aufrufe anders behandeln“
- Chrome benötigt faktisch keine Ausnahmedateien dieser Art, was die Asymmetrie zeigt, dass das Web bereits auf Chrome ausgerichtet ist
Firefoxs about:compat
- Gibt man
about:compat in die Firefox-Adressleiste ein, sieht man eine Liste site-spezifischer Eingriffe samt Schaltern
- Jeder Eintrag ist eine maßgeschneiderte Korrektur für eine bestimmte Website; schaltet man sie aus, kann man sehen, wie die Seite kaputtgeht
- Das WebCompat-System von Firefox injiziert benutzerdefiniertes CSS und JavaScript für bestimmte Domains
- Bei Websites, die den Browser falsch erkennen, wird ein geänderter User-Agent-String übermittelt
- Diese Eingriffe verdecken Bugs, damit das Web nicht kaputt wirkt; in Mozilla Bugzilla werden sogar Bug-Reports und Kontaktversuche zu den Sites nachverfolgt
Quirks in Safari
- Die WebKit-Engine von Safari nennt diese Behandlungen Quirks;
Quirks.cpp ist auf GitHub öffentlich einsehbar
- Im WebKit-Code gibt es einen Kommentar, dass Facebook, X und Reddit
<video> pausieren, wenn es aus dem sichtbaren Bereich gescrollt wird, unabhängig davon, ob der PiP-Modus aktiv ist
- Safari erkennt
facebook.com, x.com und reddit.com und ändert die Behandlung von Picture-in-Picture-Videos
- Selbst wenn der Videocode einer Site fehlerhaft ist, wartet der Browser nicht darauf, dass das jeweilige Unternehmen ihn korrigiert, sondern verteilt einen Workaround an alle Nutzer
- In einem Kommentar zu SeatGuru steht
FIXME: Remove this quirk if seatguru decides to adjust their site., was zeigt, dass die Ausnahme entfernt werden kann, sobald die Site korrigiert ist
- Das Commit-Protokoll zeigt mehrere site-spezifische Korrekturen aus den letzten Monaten
- Problem, dass Floorplan-Bilder bei Zillow nicht mittig ausgerichtet werden
- Problem, dass TikTok die Meldung „please upgrade your browser“ anzeigt
- Problem, dass Instagram Reels während der Wiedergabe unregelmäßig in der Größe geändert werden
- Problem, dass der Button „Episodes and Info“ bei Netflix ein Popover falsch schließt
- Problem, dass Twitch beim Tab-Wechsel PiP-Videos pausiert
- Problem, dass Amazon Prime Video Safari-Nutzern das Ansehen nicht erlaubt
Das Chrome-zentrierte Web und die Asymmetrie
- Die Quirks von WebKit und Firefoxs WebCompat reparieren nicht nur kaputte Websites, sondern gleichen auch aus, dass Chrome bestimmt, was als „funktioniert“ gilt
- Typischerweise führt Chrome eine Funktion ein, Entwickler nutzen sie wegen der Marktdominanz, und andere Browser müssen die Funktion nachbauen oder Unterschiede mit site-spezifischen Ausnahmen verdecken
- Wenn Safari und Firefox aufschließen, sind solche Ausnahmebehandlungen oft bereits für Millionen Nutzer ausgerollt
- WebKit enthält User-Agent-Overrides, damit Safari auf Amazon-Videoseiten und bei mehreren Streaming-Diensten wie Chrome erscheint
- Solche Sites erkennen, ob es sich um Chrome handelt, und liefern anderen Browsern eine schlechtere Erfahrung; deshalb täuscht WebKit die Browser-Identität zum Schutz der Safari-Nutzer vor
- Aktuell enthält
Quirks.cpp den folgenden gefälschten Chrome-User-Agent-String
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 arbeitet auf ähnliche Weise; viele Eingriffe in
about:compat bestehen aus User-Agent-Tarnung, die Websites signalisiert: „Ich bin Chrome“
- Das Mozilla-Wiki erklärt, dass manche Sites je nach Browsererkennung „den Zugang vollständig blockieren, ein anderes Design anzeigen oder andere Funktionen bereitstellen“
- Diese Struktur erzeugt eine Rückkopplungsschleife
- Entwickler bauen für Chrome, weil Chrome den größten Marktanteil hat
- Sites funktionieren in Chrome am besten
- Nutzer, die Bugs in anderen Browsern sehen, geben nicht der Site, sondern dem Browser die Schuld
- Nutzer wechseln zu Chrome, und Chromes Dominanz wird weiter gestärkt
- Dass Chrome kaum separate Quirks-Dateien braucht, liegt weniger an besserem Design als daran, dass das Web bereits auf Chrome zugeschnitten ist
- In einer Lage, in der Nutzer Chromium-basierter Browser über 80 % ausmachen, richten Entwickler ihre Arbeit zuerst auf Chrome aus
- Wenn eine Site in Chrome funktioniert, wird sie ausgeliefert; wenn sie in Safari oder Firefox kaputtgeht, hat das Problem geringere Priorität
- Chrome fügt nicht so sehr Ausnahmen hinzu, sondern setzt die Agenda
- Wenn Chrome ein Verhalten ändert, aktualisieren Sites sich entsprechend, und andere Browser müssen nachziehen oder kaputtgehen
Die Lücke zwischen Spezifikation und realem Web
- Browser-Ingenieure können heute sagen, dass die Spezifikationen gut definiert sind und der HTML5-Ansatz der „living specification“ das Chaos der IE-/Netscape-Zeit verringert hat
- Das Problem ist, dass Entwickler sich auf Implementierungsdetails verlassen, die nicht in der Spezifikation stehen, und bei Abweichungen in anderen Browsern dann den nicht konformen Browser verantwortlich machen
- Wenn Chromes Implementierung zum Maßstab wird, an dem sich alle orientieren, werden auch Chromes Detailverhalten außerhalb der Spezifikation zur faktischen Spezifikation
- Schon zur Zeit des Internet Explorer in den 2000ern bauten Entwickler Sites auf IE zugeschnitten, wodurch sie in anderen Browsern kaputtgingen und „funktioniert im IE“ wichtiger wurde als Standardkonformität
- Früher hoffte man, Browser-Quirks würden verschwinden, wenn sich das Web stärker an Standards hält; tatsächlich sind sie nicht verschwunden, sondern nur in Browser verlagert worden, die nicht Chrome sind
- Standards sollten browser-spezifischen Code überflüssig machen, doch nach dem Ausstieg aus der IE-Ära ist dieselbe Lücke mit einem anderen Browser im Zentrum erneut entstanden
- Heute steckt browser-spezifischer Code nicht im dominanten Browser, sondern in den nicht dominanten Browsern, die ein auf den dominanten Browser zugeschnittenes Web korrigieren
Ausnahmebehandlung reicht tiefer als gedacht
- Diese Behandlungen beschränken sich nicht auf einfache visuelle Anpassungen, sondern verändern je nach Domain das Grundverhalten des Browsers
- Allein die Liste in WebKit umfasst Tausende Zeilen, darunter Scroll-Verhalten, Verarbeitung von Touch-Events, Viewport-Berechnungen und die Behandlung von Bild-MIME-Typen
- Ein Kommentar zur Zoom-Funktion für Amazon-Produktbilder enthält Folgendes
When panning on an Amazon product image, we’re either touching on the #magnifierLens element or its previous sibling.
- Safari prüft, ob Amazon aufgerufen wurde, und ändert für die Produkt-Zoomfunktion die Art, wie Touch-Events in Maus-Events umgewandelt werden
- Weil die Amazon-Site ein bestimmtes Event-Verhalten voraussetzt, das vom Standardverhalten in Safari abweicht, liefert Safari dieses Verhalten nur für Amazon
- Auch für Storage Access, das Rendering von Scrollbars, Auto-Korrektur-Verhalten und Zoom-Verarbeitung gibt es domain-spezifische Quirks
- Jede dieser Ausnahmen ist an eine Domain-Prüfung gebunden und in das Browser-Binary einkompiliert
Warum der Browser direkt repariert, statt zu warten
- Browser-Hersteller kontaktieren problematische Sites teils und bitten um Korrekturen; im Quellcode gibt es sogar Felder mit Links zu solchen Outreach-Bemühungen
- Wenn eine populäre Site in Chrome funktioniert, im eigenen Browser aber kaputtgeht, geben Nutzer nicht der Site, sondern dem Browser die Schuld
- Statt bei Dritten einen Bug einzureichen und Wochen oder Monate zu warten, ist es aus Sicht des Browsers praktischer, am nächsten Tag einen fünfzeiligen Workaround auszurollen
- Es ist womöglich nicht einmal klar, wen man kontaktieren müsste
- Der Entwickler, der den fehlerhaften Code geschrieben hat, könnte das Unternehmen bereits verlassen haben
- Das Team, dem der betreffende Endpoint gehört, erkennt seine Verantwortung womöglich nicht
- Die Site könnte sich in einem Wartungsmodus befinden und nur noch Sicherheits-Patches erhalten
- Für den Browser ist es die einfache Wahl, das Problem sofort und unsichtbar zu beheben und so Nutzerprobleme zu reduzieren
- Ein WebKit-Ingenieur hat auch einen Beitrag über die Entfernung des FlightAware-Quirks geschrieben
- FlightAware verglich CSS-Transform-Matrix-Strings; als die CSS-Spezifikation die Serialisierung der Werte änderte und der Browser der Spezifikation folgte, ging die Site kaputt
- Die Ingenieure fügten domain-spezifischen Code hinzu, der
flightaware.com prüft; später war die Kontaktaufnahme erfolgreich, FlightAware korrigierte den Code und der Quirk wurde entfernt
- In diesen Monaten hatten Safari-Nutzer dank einer
if-Abfrage im Browser trotzdem eine normale Erfahrung
Was Entwickler prüfen sollten
- Es ist möglich, dass eine Website ohne Wissen der Entwickler speziell gerendert wird
- Solche Quirks erscheinen nicht in Fehlerprotokollen, und in der Konsole gibt es auch keine Warnung wie „Der Browser umgeht gerade einen Fehler“
- Die Workarounds arbeiten absichtlich unsichtbar
- Besonders riskant sind Sites, die hauptsächlich in Chrome getestet werden
- Dass eine Site perfekt funktioniert, kann weniger an gutem Code liegen als daran, dass Chromes Verhalten genau zu den Annahmen der Entwickler passt
- Andere Browser stehen dann vor der Wahl, die Site den Nutzern kaputt anzuzeigen oder sie in eine Quirks-Datei aufzunehmen
- Man sollte die eigene Site nicht nur gelegentlich, sondern regelmäßig in Firefox und Safari öffnen
- Quirks-Dateien existieren, weil Entwickler genau das nicht regelmäßig getan haben
- Wenn die eigene Domain in einer Quirks-Datei auftaucht, sollte geprüft werden, welche Stellen der Browser per Workaround behandelt
- Das Web hat zwar auch ohne Eingreifen der Entwickler weiter funktioniert, aber möglicherweise haben Ingenieure eines Browsers, den diese nicht nutzen, Probleme gelöst, von denen sie nichts wussten
1 Kommentare
Lobste.rs-Meinungen
Hinter dem LLM-Geschwafel steckt eine interessante Geschichte
Man kann den Schreibstil nicht mögen, und darüber will ich nicht unbedingt streiten, aber nur weil ein Text schlecht ist, heißt das nicht automatisch, dass er von einer KI geschrieben wurde. Schlechte Sätze gab es auch schon vor KI
Schade, und ich wünschte, wir würden in einer Welt leben, in der Google das Web nicht so stark beeinflusst. Der Traum vom „Web“ war viel ehrgeiziger und für mich persönlich inspirierender, deshalb ist es bedauerlich, dass es so gekommen ist
Der Zitatblock ist schwer zu lesen. Vielleicht ist das ein Dark-Mode-Problem
Dass die Details des Workarounds geteilt wurden, war aber nützlich
Der Teil „Diese Seiten erkennen, ob es Chrome ist, und liefern anderen Browsern eine abgespeckte Erfahrung. Deshalb lügt WebKit darüber, welcher Browser es ist, statt Safari-Nutzer leiden zu lassen“ scheint etwas zu sein, das sich in dieser ganzen Branche immer wiederholt
Auch Computerhersteller veröffentlichen nicht selten ACPI-Firmware, die Informationen vor nicht unterstützten Betriebssystemen versteckt, woraufhin diese Betriebssysteme schließlich gegenüber der Firmware so tun müssen, als wären sie Windows
Mir gefällt nicht, dass sich dieser Text wie ein KI-Schreibstil liest
Zusätzlich zu dem hier Genannten gibt es zwei weitere Feedback-Schleifen. Die eine ist: Chrome ist dominant, also entwickeln Leute für Chrome, dadurch funktioniert es in Chrome am besten, und wenn es in anderen Browsern Probleme gibt, geben Nutzer nicht der Website, sondern dem Browser die Schuld und wechseln zu Chrome
Die andere ist: Eine Seite ist in Firefox kaputt, aber der Betreiber sagt, in seiner Statistik sehe er keine Firefox-Nutzer. Das kann selbst dann passieren, wenn es Sonderbehandlungen wie das Umschreiben des User-Agent gibt
Soweit ich mich erinnere, hat das klassische Opera (Presto) als Erstes begonnen, solche Kompatibilitätsschichten zu implementieren
Dass die Implementierung zur Spezifikation wird, ist in diesem Bereich ein weit verbreitetes Problem. In meinem früheren Job haben wir eine Workflow-Sprache mit Konformitätstests verwendet, in der Hoffnung, dass mehrere Implementierungen entstehen und Workflows portabel werden
Das Kernproblem ist, dass es nur geringe wirtschaftliche Anreize gibt, vollständige Portabilität zu schaffen. Man möchte lieber Zusatzfunktionen in die eigene Implementierung einbauen, damit die Leute beim eigenen Produkt bleiben
Außerdem hat man keine Zeit, Software im Komitee-Stil zu bauen, also will man neue Funktionen lieber vorab selbst implementieren
Dass die Implementierung zur Spezifikation wird, liegt daran, dass wir in einer menschlichen Gesellschaft leben
Nichts Neues. Minderheiten-Browser hatten schon immer Hacks für bestimmte Seiten, früher war das Ziel eben IE. Die Alternative war nur, die Seite kaputt zu lassen
Vor Jahrzehnten bauten Webentwickler Seiten, die nur in IE funktionierten, und sagten: „Wenn du diese Seite nutzen willst, dann nimm IE.“ Heute wiederholt sich dasselbe mit Chrome. Ob Chrome nun richtig oder falsch liegt, ist dabei egal. Die Seite funktioniert nur in Chrome, und wenn andere Browser auf dieser Seite nicht das Verhalten von Chrome garantieren, sagen die Leute: „Dieser Browser ist kaputt“, und wechseln zu Chrome
Ich frage mich wirklich, ob die Leute denken, Gecko und WebKit müssten solche Seiten aus Prinzip kaputt lassen, oder ob sie meinen, alle sollten einfach Chrome benutzen und keine anderen Browser. Zur Alternative zu seitenspezifischen Hacks gehören nur diese beiden Möglichkeiten
Ich finde es schon komisch, dass Firefox und Safari sich per User-Agent als Chrome ausgeben
Andererseits trägt der User-Agent-String von Chrome noch immer fossilartige Spuren davon, sich als Mozilla-Browser und als Apple-Browser auszugeben
In dieser einen Codezeile liegen ganze geologische Schichten: