www.google.com – The page is blank when accessed

A server-side user-agent bug caused Google’s homepage to render as a blank page in Firefox for Android, apparently for all Firefox versions ≥65, while other browsers and search entry from the address bar continued to work. Commenters debate whether this reflects deliberate friction against a low‑share competitor or simple negligence amplified by Google’s Chrome‑centric testing practices, noting that Mozilla is responding by overriding the user agent for Google in Firefox. The incident rekindles criticism of UA sniffing in general, concerns about Chrome’s dominance and web interoperability, and frustration that browser vendors must ship site-specific workarounds for large platforms.

Technical cause and scope

  • Bug traced to server-side User-Agent sniffing on www.google.com.
  • Firefox for Android with version ≥65 receives an HTML document containing only a doctype (blank page); ≤64 works.
  • The problematic combination is “Android” + “Firefox”; removing those tokens from the UA string makes the page load normally.
  • Issue affects the search homepage, not address-bar searches, and disappears when Firefox is put in “desktop mode” (different UA).

Testing and QA practices

  • Many commenters argue Google likely doesn’t test on Firefox Android at all, focusing on Chrome (desktop/mobile), Safari, Edge, and maybe Firefox desktop.
  • Some describe Google’s rollout model (staged percentage launches plus metrics) and say Firefox Android’s tiny share means regressions may never trip rollout gates.
  • Others find the lack of automated tests covering Firefox mobile surprising given Google’s size.

Intent vs. negligence

  • One camp sees this as part of a long-standing pattern of Google “accidental” breakages affecting Firefox (YouTube, Maps, sports scores, weather, image search).
  • They argue repeated “oops” incidents and non-support amount to de facto sabotage, or at least anti-competitive neglect.
  • Another camp thinks deliberate sabotage is unlikely: Firefox’s existence helps Google’s antitrust optics, and more plausible explanations are low priority and internal Chrome-centric culture.
  • Several note that, from a user-impact perspective, negligence vs. malice doesn’t change the harm.

Mozilla/browser-side workarounds

  • Firefox maintains compatibility shims (about:compat) including UA overrides, injected scripts, and tracker-blocking exceptions.
  • Mozilla appears ready to ship an emergency patch overriding the UA for Google; some call this “insane,” others note OSes and browsers routinely carry app/site-specific hacks to keep popular services working.

User-Agent sniffing debate

  • Many criticize UA sniffing as fragile and unnecessary for something as basic as a search page; feature detection is preferred.
  • Others defend limited UA-based handling for known browser bugs, performance tuning, or version-specific quirks, while warning against broad whitelists/blacklists.
  • The irony is noted that Google has also pushed UA-string freezing, yet is bitten by UA parsing.

Alternatives and user behavior

  • Several users report they didn’t notice because they already use alternative search engines (Kagi, DuckDuckGo, Brave Search).
  • Discussion includes pros/cons of these services and user techniques like DDG “bangs” and domain blocking.

Meta: HN and issue trackers

  • The GitHub issue was locked once it hit HN; maintainers stressed that bug trackers are workplaces, not discussion forums.
  • Commenters generally agree that large external communities piling into issue trackers adds noise and justifies locking.