Leere Seite beim Aufruf von www.google.com

 (github.com/webcompat)
1 Punkte von GN⁺ 2024-01-10 | 1 Kommentare | Auf WhatsApp teilen
  • In Firefox Mobile 121.0 unter Android wurde ein webcompat-Issue registriert, bei dem https://www.google.com/ als leere Seite angezeigt wird und zentrale Funktionen der Google-Suche dadurch nicht nutzbar sind
  • In Reproduktionstests trat dasselbe Problem sowohl mit Firefox Release 121.0.1 als auch mit Firefox Nightly 123.0a1 auf; in Chrome 120.0.6099.43 ließ es sich nicht reproduzieren
  • Wird ETP deaktiviert, erscheint zwar das Cookie-Banner, doch auch nach Zustimmung bleibt der Seiteninhalt weiterhin leer, sodass das Problem nicht behoben ist
  • Das zugehörige Mozilla-Bugzilla-Issue wurde mit 1873601 verknüpft; bei Bedarf stand ein Patch zur Auslieferung als Dot-Release bereit
  • Später begann Google mit der Auslieferung eines Fixes; nach mehrstündiger Beobachtung schien das Problem für die meisten Nutzer behoben zu sein, weshalb entschieden wurde, das Issue als fixed zu schließen

Aufgetretenes Problem und erstmals gemeldete Umgebung

  • Die betroffene URL ist https://www.google.com/; der Problemtyp wurde als Site is not usable registriert
  • Das gemeldete Symptom ist, dass die Google-Seite nicht korrekt lädt und als leerer Bildschirm angezeigt wird
  • Erstgemeldete Umgebung:
    • Browser: Firefox Mobile 121.0
    • Betriebssystem: Android 13
    • Test mit anderem Browser: Yes Other
  • Die Browser-Einstellungen enthielten folgende Werte:
    • gfx.webrender.all: false
    • gfx.webrender.blob-images: true
    • gfx.webrender.enabled: false
    • buildID: 20231230165955
    • channel: release
    • hasTouchScreen: true
    • mixed active/passive content blocked: false
    • tracking content blocked: false

Reproduktionsergebnisse und Vergleichsbrowser

  • Die für die Reproduktion zuständige Person konnte das Problem reproduzieren
  • Testumgebung:
    • Firefox Nightly 123.0a1-20240108213208
    • Firefox Release 121.0.1-20231230165955
    • Chrome 120.0.6099.43
    • Gerät: OnePlus 6 A6000
    • Betriebssystem: Android 11
    • Display: 1080 x 2280, 19:9, ca. 402 ppi
  • Reproduktionsergebnisse:
    • In Firefox Release und Nightly jeweils reproduzierbar
    • In Chrome nicht reproduzierbar
  • Das Issue wurde den Kategorien Firefox Mobile, Gecko-Engine und Fehlschlag beim Seitenladen zugeordnet

Test mit deaktiviertem ETP

  • Wird ETP deaktiviert, erscheint das Cookie-Banner
  • Auch nach Akzeptieren des Cookie-Banners wird der Inhalt der Google-Seite nicht angezeigt und bleibt weiterhin ein leerer Bildschirm
  • Allein auf Grundlage dieses Testergebnisses ist das Deaktivieren von ETP keine Lösung des Problems

Diagnose und zugehörige Issues

  • Das Issue wurde in den Status needsdiagnosis verschoben
  • Der zugehörige Mozilla-Bugzilla-Bug wurde als 1873601 querverwiesen
  • Am selben Tag wurden mehrere ähnliche Google-bezogene Issues verknüpft:

Fortschritt beim Fix und weiteres Vorgehen

  • Die zuständige Person erklärte, dass bei Bedarf ein Patch zur Auslieferung als Dot-Release bereitstehe
  • Nach damaligem Stand wurde eingeschätzt, dass dieser Patch möglicherweise nicht benötigt wird
  • Anschließend begann Google, einen Fix auszurollen; nach mehrstündiger Beobachtung schien das Problem für die meisten Nutzer behoben zu sein
  • Für verbliebene Nutzer, bei denen weiterhin ein leerer Bildschirm in Google Search auftritt und das Problem per UA-Spoofing behoben werden kann, blieb die Diskussion entsperrt
  • Wenn dieselben Symptome weiterhin auftreten, kann ein neuer Bug im Triage-Prozess besser erfasst werden als ein Kommentar im bestehenden Issue

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-01-10
Hacker-News-Kommentare

  • Der Kern des Problems ist, wie in https://github.com/webcompat/web-bugs/issues/131916#issuecomment-1882627241 beschrieben, ein komplett fehlerhaftes serverseitiges UA-Sniffing
    Wenn man mit einer Firefox-Android-UA anfragt, wird ein leeres HTML-Dokument zurückgegeben, das nur den doctype enthält; auch mit curl lässt sich das reproduzieren
    $ curl -H "User-Agent: Mozilla/5.0 (Android 10; Mobile; rv:123.0) Gecko/123.0 Firefox/123.0" https://www.google.com
    Offenbar sind alle UA-Strings mit Version 65 oder höher betroffen, während 64 und darunter zu funktionieren scheinen

    • Genauer gesagt betrifft es Firefox Mobile
      Der UA-String, den Firefox Mobile im Desktop-Modus sendet, bekam eine normale Antwort
    • Vor ein paar Wochen habe ich dieses Verhalten auch etwa eine Woche lang bei Gmail unter Linux Firefox gesehen

  • Ich arbeite bei Google Search. Das tut mir wegen dieses Vorfalls leid. Inzwischen ist es behoben und auch im Search-Status-Dashboard vermerkt: https://status.search.google.com/incidents/hySMmncEDZ7Xpaf9i32C

    • Zum Glück wurde es auf der Hacker-News-Startseite, dem passenden und offenbar einzigen Ort für Google-Support, gemeldet
    • Ich würde gern hören, was für ein Bug das war und wie ihr ihn behoben habt
    • So etwas ist sicher stressig, wenn es passiert. Software ist ein schwieriges Feld, und es gibt extrem viele Dinge, die schiefgehen können
      Wenn man bedenkt, wie selten große Dienste im Verhältnis Fehler und Ausfälle haben, bekommt man ein Gefühl dafür, wie viel Arbeit dahintersteckt

  • Google arbeitet mit Mozilla zusammen, um ein werbefreies Sucherlebnis zu bieten

    • Zufällig wurde daraus auch ein Erlebnis ohne Suche

  • Google verfolgt den Vorfall hier: https://status.search.google.com/incidents/hySMmncEDZ7Xpaf9i32C
    Zur Offenlegung: Ich arbeite bei Google, bin aber für diesen Fall nicht zuständig. Ich habe den Link im Bugzilla-Bug gesehen

    • Ich verstehe nicht, warum das nicht einfach ein Rollback ist. Selbst im schlimmsten Fall sollte doch ein Revert-Commit mit anschließendem Redeploy reichen
      Dass ein Problem in einem etwas weniger verbreiteten Browser auftaucht, verstehe ich, aber für Google-Ingenieure sollte die eigentliche Behebung doch eher trivial sein

  • An den Einreicher: „Bitte verwendet den Originaltitel und bearbeitet ihn nicht, es sei denn, er ist irreführend oder reißerisch.“ — https://news.ycombinator.com/newsguidelines.html
    Wenn du sagen willst, was du an dem Artikel wichtig findest, schreib es einfach als Kommentar in den Thread. Dann ist es unter denselben Bedingungen sichtbar wie die Beiträge aller anderen: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&sort=byDate&type=comment&query=%22level%20playing%20field%22%20by:dang
    Der eingereichte Titel war: „Google breaks search for Firefox users because of bad UA string sniffing“

  • Das erinnert mich an einen Blogpost eines ehemaligen Mozilla-Managers, der schrieb, Google habe absichtlich Probleme verursacht, um Nutzer zu Chrome zu bewegen
    https://news.ycombinator.com/item?id=38349357

    • Wird das hier auch so gesehen? Dass Google die Suchseite absichtlich leer gemacht habe, um Firefox-Nutzer zu Chrome zu treiben?
      Oder liegt es eher näher an Hanlons Rasiermesser

  • https://github.com/webcompat/web-bugs/issues/131916#issuecomment-1882627241
    Das ist ein glasklarer Fall von fehlerhaftem serverseitigem UA-Sniffing. Wenn man mit einer Firefox-Android-UA anfragt, bekommt man ein leeres HTML-Dokument, das nur den doctype enthält
    Mit curl ist es reproduzierbar, und offenbar sind alle UA-Strings mit Version 65 oder höher betroffen. 64 und darunter funktionieren

    • Interessant ist, dass mehr Inhalt zurückkommt, wenn man „Android“ aus der UA entfernt, dass ohne „Mobile“ immer noch nur der doctype kommt und dass das Problem komplett verschwindet, wenn man „Firefox“ entfernt

  • Gibt es überhaupt einen legitimen Grund, UA-String-Erkennung statt Feature Detection zu verwenden? Und wie moderne Features müsste eine Suchmaschine überhaupt einsetzen, damit sie nicht in allen Browsern funktioniert?

    • Es gab ein paar Fälle; der erste, der mich betraf, war, als Chrome verlangte, dass der SameSite=None-Schalter im Set-Cookie-Header für Drittanbieter-Kontexte gesetzt wird[1]

      Warnung: Einige ältere Versionen von Chrome, Safari und UC browser sind mit dem neuen None-Attribut nicht kompatibel und können Cookies ignorieren oder einschränken
      Wegen dieser Einschränkung war UA-Sniffing die einzige verlässliche Methode, um Cookies so zu setzen, dass korrektes Verhalten garantiert war
      1: https://web.dev/articles/samesite-cookies-explained

    • Um Nutzer auf neue und aufregende Weise zu tracken
    • Ich habe Fälle gesehen, in denen sich Browser auf subtile Weise unterschiedlich verhalten. Um die Auswirkungen zu verringern, während wir nach dem richtigen Fix gesucht haben, haben wir je nach Browser unterschiedliche Inhalte ausgeliefert, damit betroffene Nutzer eine funktionierende Erfahrung bekommen
      Das hat nichts mit Feature Detection zu tun, daher greifen die üblichen Vorschläge hier nicht
    • Wenn man das Betriebssystem des Nutzers erkennt, um den passenden Binärdownload-Link anzubieten?
    • Eine auffällige Eigenschaft der Google-Such-Startseite ist, wie absurd schnell sie ist. Nach dem ersten Tastendruck antwortet sie innerhalb von 200 ms mit 10 Vorschlägen inklusive Text und Grafiken und macht dann genauso weiter
      Meine RTT zu www.google.com liegt bei ungefähr 20 ms, also gehen davon mindestens 100 ms fürs Internet drauf
      Solche Geschwindigkeiten erreicht man nicht ohne starke Optimierung. Ehrlich gesagt würde es mich wundern, wenn www.google.com nicht die am stärksten optimierte Seite im ganzen Internet wäre
      Deshalb überrascht es mich überhaupt nicht, dass je nach anfragendem Browser unterschiedlich optimiert wird

  • Ich hätte nicht gedacht, dass ich darüber lachen würde, aber ein Screenshot, der nur aus einem reinweißen Rechteck besteht, war auf seltsame Weise komisch