Page vide lors de l’accès à www.google.com

 (github.com/webcompat)
1 points par GN⁺ 2024-01-10 | 1 commentaires | Partager sur WhatsApp
  • Sur Firefox Mobile 121.0 pour Android, un problème de webcompat a été signalé : lors de l’accès à https://www.google.com/, la page s’affiche vide, empêchant l’utilisation des fonctions essentielles de Google Search
  • Les tests de reproduction ont montré que le même problème se produisait sur Firefox Release 121.0.1 et Firefox Nightly 123.0a1, alors qu’il ne se reproduisait pas sur Chrome 120.0.6099.43
  • Lorsque l’ETP est désactivé, la bannière de cookies s’affiche, mais même après acceptation, le contenu principal de la page reste vide, ce qui ne résout pas le problème
  • Le bug Mozilla Bugzilla associé a été relié à 1873601, et un correctif prêt à être livré en dot-release était disponible si nécessaire
  • Par la suite, Google a commencé à déployer un correctif et, après quelques heures d’observation, il a été estimé que le problème était résolu pour la grande majorité des utilisateurs, ce qui a conduit à la fermeture du ticket en tant que fixed

Problème constaté et environnement de signalement initial

  • L’URL concernée est https://www.google.com/ et le type de problème a été enregistré comme Site is not usable
  • Le symptôme signalé est que la page Google ne se charge pas correctement et s’affiche comme un écran vide
  • Environnement initial de signalement :
    • Navigateur : Firefox Mobile 121.0
    • Système d’exploitation : Android 13
    • Test sur d’autres navigateurs : Yes Other
  • Les paramètres du navigateur incluaient les valeurs suivantes :
    • 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

Résultats de reproduction et navigateur de comparaison

  • La personne chargée de la reproduction a pu reproduire ce problème
  • Environnement de test :
    • Firefox Nightly 123.0a1-20240108213208
    • Firefox Release 121.0.1-20231230165955
    • Chrome 120.0.6099.43
    • Appareil : OnePlus 6 A6000
    • Système d’exploitation : Android 11
    • Écran : 1080 x 2280, 19:9, environ 402 ppi
  • Résultats de reproduction :
    • Reproduit à la fois sur Firefox Release et Nightly
    • Non reproduit sur Chrome
  • Le ticket a été classé dans les catégories Firefox Mobile, moteur Gecko et échec de chargement de page

Test avec désactivation de l’ETP

  • Lorsque l’ETP est désactivé, la bannière de cookies apparaît
  • Même après avoir accepté la bannière de cookies, le contenu principal de la page Google ne s’affiche pas et reste dans un état d’écran vide
  • Ce test à lui seul ne permet donc pas de considérer la désactivation de l’ETP comme une solution

Diagnostic et tickets associés

  • Le ticket est passé à l’étape needsdiagnosis
  • Le bug Mozilla Bugzilla associé a été croisé avec 1873601
  • Le même jour, plusieurs tickets similaires liés à Google ont été associés :

Avancement du correctif et orientation du traitement

  • Le responsable a indiqué qu’un correctif prêt à être diffusé en dot-release était disponible si nécessaire
  • À ce stade, il a été estimé que ce correctif ne serait peut-être pas nécessaire
  • Par la suite, Google a commencé à déployer un correctif et, après quelques heures d’observation, il a semblé que le problème était résolu pour la grande majorité des utilisateurs
  • Le verrouillage de la discussion a été levé pour les utilisateurs encore touchés par le problème d’écran vide dans Google Search et pour lesquels un UA spoof pouvait constituer une solution
  • Si le même symptôme persiste, il peut être préférable d’ouvrir un nouveau bug plutôt que de commenter le ticket existant, afin qu’il soit mieux pris en compte dans le processus de triage

À lire aussi

1 commentaires

 
GN⁺ 2024-01-10
Avis sur Hacker News

  • Le point essentiel, comme indiqué dans https://github.com/webcompat/web-bugs/issues/131916#issuecomment-1882627241, est qu’il s’agit d’un cas où la détection de l’UA côté serveur est complètement erronée
    Quand on envoie une requête avec l’UA de Firefox Android, on reçoit un document HTML vide qui ne contient que le doctype, et c’est reproductible avec curl
    $ curl -H "User-Agent: Mozilla/5.0 (Android 10; Mobile; rv:123.0) Gecko/123.0 Firefox/123.0" https://www.google.com
    Toutes les chaînes d’UA de version 65 ou supérieure semblent touchées, tandis que les versions 64 et inférieures semblent fonctionner

    • Plus précisément, il s’agit de Firefox Mobile
      La chaîne d’UA envoyée par Firefox Mobile en mode bureau recevait une réponse normale
    • Il y a quelques semaines, j’ai aussi observé ce phénomène pendant une semaine sur Gmail avec Firefox sous Linux

  • Je travaille sur Google Search. Désolé pour cet incident. C’est maintenant corrigé et cela figure aussi sur le tableau de bord de l’état de la recherche : https://status.search.google.com/incidents/hySMmncEDZ7Xpaf9i32C

    • Heureusement, cela a été signalé au bon et unique endroit permettant d’obtenir le support de Google : la une de Hacker News
    • J’aimerais savoir quel était le bug et comment il a été corrigé
    • Quand ce genre de chose arrive, ça doit être très stressant. Le logiciel est un domaine difficile, et il y a énormément d’éléments susceptibles de mal tourner
      Quand on pense au fait que les grands services connaissent relativement peu d’erreurs et d’interruptions, on réalise la quantité de travail qu’il y a derrière

  • Google coopère avec Mozilla pour offrir une expérience de recherche sans publicité

    • Par coïncidence, c’est aussi devenu une expérience sans recherche

  • Google suit cet incident ici : https://status.search.google.com/incidents/hySMmncEDZ7Xpaf9i32C
    Pour être transparent, je travaille chez Google, mais je ne m’occupe pas de ce dossier. J’ai vu ce lien dans le bug Bugzilla

    • Je ne comprends pas pourquoi ce n’est pas simplement un rollback. Au pire, il suffirait de revenir au commit précédent puis de redéployer
      Je comprends qu’un problème puisse survenir sur un navigateur un peu moins courant, mais j’aurais tendance à penser que la correction elle-même devrait être triviale pour un ingénieur Google

  • Au contributeur : « Utilisez le titre original, sauf s’il est trompeur ou racoleur, et ne le modifiez pas. » — https://news.ycombinator.com/newsguidelines.html
    Si vous voulez dire ce que vous jugez important dans l’article, vous pouvez le faire en commentaire dans le fil. Cela le placera alors au même niveau de visibilité que les autres : https://hn.algolia.com/?dateRange=all&page=0&prefix=false&sort=byDate&type=comment&query=%22level%20playing%20field%22%20by:dang
    Le titre soumis était « Google breaks search for Firefox users because of bad UA string sniffing »

  • Cela me rappelle un billet de blog d’un ancien dirigeant de Mozilla qui écrivait que Google provoquait délibérément des problèmes pour pousser les utilisateurs vers Chrome
    https://news.ycombinator.com/item?id=38349357

    • Est-ce qu’on pense que c’est aussi ce qui s’est passé ici ? Que Google aurait rendu la page de recherche blanche pour envoyer les utilisateurs de Firefox vers Chrome ?
      Ou bien est-ce peut-être plus proche du rasoir de Hanlon

  • https://github.com/webcompat/web-bugs/issues/131916#issuecomment-1882627241
    C’est entièrement un cas de détection de l’UA côté serveur qui tourne mal. Avec une requête utilisant l’UA de Firefox Android, on reçoit un document HTML vide ne contenant que le doctype
    C’est reproductible avec curl, et toutes les chaînes d’UA de version 65 ou supérieure semblent touchées. Les versions 64 et inférieures fonctionnent

    • Il est intéressant de noter que si l’on retire « Android » de l’UA, on reçoit davantage de contenu ; si l’on retire « Mobile », on reçoit toujours seulement le doctype ; et si l’on retire « Firefox », le problème est entièrement résolu

  • Y a-t-il une raison valable d’utiliser la détection de chaîne d’UA au lieu de la détection de fonctionnalités ? Et à quel point un moteur de recherche doit-il utiliser des fonctionnalités modernes pour risquer de ne pas fonctionner dans tous les navigateurs ?

    • Il y a eu plusieurs cas ; le premier qui m’a touché était le changement de Chrome exigeant le flag SameSite=None sur l’en-tête Set-Cookie dans les contextes tiers[1]

      Attention : certaines anciennes versions de Chrome, Safari et UC browser ne sont pas compatibles avec le nouvel attribut None et peuvent ignorer ou restreindre le cookie
      À cause de cette contrainte, la détection de l’UA était le seul moyen fiable de définir un cookie dont le fonctionnement correct était garanti
      1 : https://web.dev/articles/samesite-cookies-explained

    • Pour suivre les utilisateurs de façons nouvelles et enthousiasmantes
    • J’ai vu des cas où les navigateurs se comportaient de manière subtilement différente. Pendant que nous cherchions la bonne correction, nous avons servi du contenu différent selon le navigateur afin de réduire l’impact et de proposer à ces utilisateurs une expérience fonctionnelle
      Cela n’a rien à voir avec la détection de fonctionnalités, donc les suggestions habituelles ne s’appliquent pas
    • Par exemple pour détecter le système d’exploitation de l’utilisateur et fournir le bon lien de téléchargement du binaire ?
    • Une chose qui saute aux yeux sur la page d’accueil de Google Search, c’est qu’elle est incroyablement rapide. Elle répond en moins de 200 ms après la première frappe avec 10 suggestions contenant du texte et des images, et continue à fonctionner ainsi
      Mon aller-retour vers www.google.com est d’environ 20 ms, donc au moins 100 ms sont consommées sur Internet
      Une telle vitesse n’existe pas sans une forte optimisation. En fait, il serait surprenant que www.google.com ne soit pas la page la plus optimisée d’Internet
      Il n’est donc pas du tout surprenant qu’ils optimisent en fonction du navigateur qui émet la requête

  • Je ne m’attendais pas à rire, mais la capture d’écran qui n’était qu’un rectangle blanc pur m’a curieusement fait rire