www.google.com アクセス時にページが空白になる現象

 (github.com/webcompat)
1 ポイント 投稿者 GN⁺ 2024-01-10 | 1件のコメント | WhatsAppで共有
  • Android の Firefox Mobile 121.0 で https://www.google.com/ にアクセスするとページが空白画面として表示され、Google 検索の中核機能を利用できない webcompat イシューが登録された
  • 再現テストでは Firefox Release 121.0.1 と Firefox Nightly 123.0a1 の両方で同じ問題が発生し、Chrome 120.0.6099.43 では再現しなかった
  • ETP を無効化すると クッキーバナー は表示されるが、同意後もページ本文は引き続き空白画面のままで、問題は解決しなかった
  • 関連する Mozilla Bugzilla イシューは 1873601 に紐付けられ、必要であれば dot-release で配布するパッチが準備されていた
  • その後 Google が修正の展開を開始し、数時間にわたって観察した結果、大多数のユーザー では問題が解消されたように見えたため、イシューを fixed としてクローズする判断が示された

発生した問題と最初の報告環境

  • 対象 URL は https://www.google.com/ で、問題種別は Site is not usable として登録された
  • 報告された症状は、Google ページが正常に読み込まれず 空白画面 として表示される現象だった
  • 最初の報告環境:
    • ブラウザー: Firefox Mobile 121.0
    • OS: Android 13
    • 他ブラウザーでのテスト: Yes Other
  • ブラウザー設定には次の値が含まれていた:
    • 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

再現結果と比較ブラウザー

  • 再現担当者はこの問題を再現できた
  • テスト環境:
    • Firefox Nightly 123.0a1-20240108213208
    • Firefox Release 121.0.1-20231230165955
    • Chrome 120.0.6099.43
    • デバイス: OnePlus 6 A6000
    • OS: Android 11
    • 画面: 1080 x 2280, 19:9, 約 402 ppi
  • 再現結果:
    • Firefox Release と Nightly の両方で再現した
    • Chrome では再現しなかった
  • イシューは Firefox Mobile、Gecko エンジン、ページ読み込み失敗 系として分類された

ETP 無効化テスト

  • ETP を無効化するとクッキーバナーは表示された
  • クッキーバナーを受け入れても Google ページ本文は表示されず、引き続き 空白画面 のままだった
  • このテスト結果だけでは、ETP の無効化は問題の解決策にならなかった

診断と関連イシュー

  • イシューは needsdiagnosis 段階へ移行した
  • 関連する Mozilla Bugzilla バグは 1873601 として相互参照された
  • 同じ日に類似の Google 関連イシューが複数紐付けられた:

修正の進行と対応方針

  • 担当者は、必要であれば dot-release で配布するパッチが準備できていると明らかにした
  • 当時の状況では、そのパッチは不要になる可能性があると判断された
  • その後 Google が修正の展開を開始し、数時間にわたって進行状況を観察した結果、大多数のユーザー では問題が解消されたように見えた
  • Google Search の空白画面問題が残っていて、UA spoof で解決できるケースに対応するため、会話のロックは解除された
  • 同じ症状が続く場合は、既存イシューにコメントを残すよりも新しいバグを登録したほうが、triage プロセスでより適切に拾われる可能性がある

関連記事

1件のコメント

 
GN⁺ 2024-01-10
Hacker Newsのコメント

  • 要点は、https://github.com/webcompat/web-bugs/issues/131916#issuecomment-1882627241 にあるように、サーバー側のUA判定が完全に間違っていたケースだということ
    Firefox AndroidのUAでリクエストすると、doctypeだけの空のHTMLドキュメントが返ってきて、curlでも再現できる
    $ curl -H "User-Agent: Mozilla/5.0 (Android 10; Mobile; rv:123.0) Gecko/123.0 Firefox/123.0" https://www.google.com
    バージョンが65以上のUA文字列はすべて影響を受け、64以下は動作するようだ

    • 正確には Firefox Mobile
      Firefox Mobileがデスクトップモードで送るUA文字列では正常なレスポンスが返ってきた
    • 数週間前ごろ、1週間ほどLinux Firefoxの Gmail でもこの現象を見た

  • Google Searchで働いている。今回の件は申し訳ない。もう修正済みで、検索ステータスダッシュボードにも掲載された: https://status.search.google.com/incidents/hySMmncEDZ7Xpaf9i32C

    • 幸い、Googleのサポートを受けられる適切かつ唯一の場所である Hacker Newsのトップページ に報告された
    • どんなバグで、どう直したのか聞いてみたい
    • こういうことが起きるとストレスが大きそう。ソフトウェアは難しい分野で、うまくいかなくなり得る要素がものすごく多い
      大規模サービスが比較的少ないエラーや停止で運用されていることを考えると、その裏に相当な作業量があるのだと実感する

  • GoogleがMozillaと協力して、広告のない検索体験を提供している

    • 偶然にも、検索もない体験になった

  • Googleはこの障害をここで追跡している: https://status.search.google.com/incidents/hySMmncEDZ7Xpaf9i32C
    開示しておくとGoogleで働いているが、この件の担当ではない。Bugzillaのバグでこのリンクを見た

    • なぜこれが単なるロールバックではないのか理解できない。最悪でも、巻き戻しコミット後に再デプロイすればよさそうなのに
      やや一般的でないブラウザで問題が起きたのは理解できるが、Googleのエンジニアにとって修正自体は些細なものではないかと思う

  • 投稿者へ: 「誤解を招く、または釣りっぽいタイトルでないなら原文タイトルを使い、編集しないでください。」 — https://news.ycombinator.com/newsguidelines.html
    記事で重要だと思う内容を言いたいなら、スレッドにコメントすればよい。そうすれば他の人と同じ条件で見える: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&sort=byDate&type=comment&query=%22level%20playing%20field%22%20by:dang
    投稿されたタイトルは “Google breaks search for Firefox users because of bad UA string sniffing” だった

  • Mozillaの元幹部が、GoogleがユーザーをChromeへ移行させるために意図的に問題を起こしたと書いたブログ記事を思い出す
    https://news.ycombinator.com/item?id=38349357

    • ここでもそういうことが起きたと見ているのか？ GoogleがFirefoxユーザーをChromeへ誘導するために検索ページを真っ白な画面にしたということなのか？
      それともハンロンの剃刀に近い話かもしれない

  • https://github.com/webcompat/web-bugs/issues/131916#issuecomment-1882627241
    これは完全にサーバー側のUA判定が間違っていた事例。Firefox AndroidのUAでリクエストすると、doctypeだけの空のHTMLドキュメントを受け取る
    curlで再現可能で、バージョン65以上のすべてのUA文字列に影響があるようだ。64以下は動作する

    • UAから “Android” を外すとより多くの内容が返り、“Mobile” を外しても依然としてdoctypeだけが返り、“Firefox” を外すと完全に直る点が興味深い

  • 機能検出の代わりにUA文字列判定を使う正当な理由はあるのか？ そして検索エンジンが一体どれほど最新機能を使えば、すべてのブラウザで動作しなくなり得るのか？

    • いくつか事例はあったが、自分に最初に影響したのは、ChromeがサードパーティのコンテキストでSet-Cookieヘッダーに SameSite=None フラグを要求するよう変更した件だった[1]

      警告: Chrome、Safari、UC browserの一部の古いバージョンは新しいNone属性と互換性がなく、Cookieを無視または制限する可能性がある
      この制約のため、正常に動作することが保証されたCookieを設定するには、UA判定が唯一信頼できる方法だった
      1: https://web.dev/articles/samesite-cookies-explained

    • 新しくて刺激的な方法でユーザーを追跡するため
    • ブラウザが微妙に異なる動作をするケースを見てきた。正しい修正方法を見つけるまで影響を抑えるため、そのユーザーには動作する体験を提供できるようにブラウザ別の異なるコンテンツを返したことがある
      これは機能検出とは関係ないので、よくある提案は通用しない
    • ユーザーのOSを検出して、適切なバイナリのダウンロードリンクを提供する場合？
    • Google検索ホームページで目立つ点の一つは、速度が非常に速いこと。最初のキー入力から200ms以内にテキストと画像を含む候補10件で応答し、そのまま動作し続ける
      自分の www.google.com への往復時間は約20msなので、そのうち少なくとも100msはインターネット上で消費されていることになる
      この速度は強力な最適化なしには出ない。実際、http://google.comがインターネット上で最も最適化されたページでなければ驚くほどだ/
      だから、どのブラウザがリクエストしているかに応じて最適化するのはまったく不思議ではない

  • 笑うとは思わなかったが、純粋な白い四角形だけのスクリーンショットが妙におかしかった