Página em branco ao acessar www.google.com

 (github.com/webcompat)
1 pontos por GN⁺ 2024-01-10 | 1 comentários | Compartilhar no WhatsApp
  • No Firefox Mobile 121.0 no Android, foi registrado um problema de webcompat em que, ao acessar https://www.google.com/, a página era exibida em branco, impedindo o uso das funções principais da Busca Google
  • Nos testes de reprodução, o mesmo problema ocorreu tanto no Firefox Release 121.0.1 quanto no Firefox Nightly 123.0a1, enquanto no Chrome 120.0.6099.43 o erro não foi reproduzido
  • Ao desativar o ETP, o banner de cookies passou a aparecer, mas mesmo após consentir, o conteúdo principal da página continuava em branco, então o problema não foi resolvido
  • O issue correspondente no Mozilla Bugzilla foi vinculado como 1873601, e já havia um patch preparado para ser distribuído em um dot-release, se necessário
  • Depois, o Google começou a distribuir uma correção e, após algumas horas de observação, concluiu-se que o problema parecia resolvido para a grande maioria dos usuários, levando ao fechamento do issue como fixed

Problema ocorrido e ambiente do relato inicial

  • A URL afetada era https://www.google.com/, e o tipo do problema foi registrado como Site is not usable
  • O sintoma relatado era que a página do Google não carregava corretamente e era exibida como tela em branco
  • Ambiente do relato inicial:
    • Navegador: Firefox Mobile 121.0
    • Sistema operacional: Android 13
    • Teste em outro navegador: Yes Other
  • As configurações do navegador incluíam os seguintes valores:
    • 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

Resultado da reprodução e navegador de comparação

  • O responsável pela reprodução conseguiu reproduzir o problema
  • Ambiente de teste:
    • Firefox Nightly 123.0a1-20240108213208
    • Firefox Release 121.0.1-20231230165955
    • Chrome 120.0.6099.43
    • Dispositivo: OnePlus 6 A6000
    • Sistema operacional: Android 11
    • Tela: 1080 x 2280, 19:9, cerca de 402 ppi
  • Resultado da reprodução:
    • O problema ocorreu tanto no Firefox Release quanto no Nightly
    • No Chrome, não foi reproduzido
  • O issue foi classificado na linha de Firefox Mobile, motor Gecko e falha no carregamento da página

Teste com ETP desativado

  • Ao desativar o ETP, o banner de cookies aparecia
  • Mesmo aceitando o banner de cookies, o conteúdo principal da página do Google não era exibido e continuava em tela em branco
  • Só esse resultado de teste não indicava que desativar o ETP fosse uma solução para o problema

Diagnóstico e issues relacionados

  • O issue foi movido para a etapa needsdiagnosis
  • O bug relacionado no Mozilla Bugzilla foi referenciado de forma cruzada como 1873601
  • No mesmo dia, vários issues semelhantes relacionados ao Google também foram vinculados:

Andamento da correção e encaminhamento

  • O responsável informou que havia um patch pronto para distribuição em um dot-release, se necessário
  • Naquele momento, avaliou-se que talvez esse patch não fosse necessário
  • Depois disso, o Google começou a distribuir uma correção e, após observar o andamento por algumas horas, pareceu que o problema havia sido resolvido para a grande maioria dos usuários
  • A conversa permaneceu desbloqueada para casos de usuários que ainda enfrentassem a tela em branco na Busca Google e conseguissem resolver com UA spoof
  • Se o mesmo sintoma continuar ocorrendo, pode ser mais eficaz registrar um novo bug em vez de comentar no issue existente, para que ele seja melhor capturado no processo de triagem

Leituras relacionadas

1 comentários

 
GN⁺ 2024-01-10
Opiniões no Hacker News

  • O ponto central é que, como aparece em https://github.com/webcompat/web-bugs/issues/131916#issuecomment-1882627241, trata-se de um caso em que a detecção de UA no lado do servidor estava completamente errada
    Ao fazer a requisição com o UA do Firefox Android, vinha um documento HTML vazio só com o doctype, e era reproduzível também com curl
    $ curl -H "User-Agent: Mozilla/5.0 (Android 10; Mobile; rv:123.0) Gecko/123.0 Firefox/123.0" https://www.google.com
    Todas as strings de UA com versão 65 ou superior eram afetadas, e 64 ou inferiores pareciam funcionar

    • Mais precisamente, era o Firefox Mobile
      A string de UA que o Firefox Mobile envia no modo desktop recebia uma resposta normal
    • Algumas semanas antes, vi esse fenômeno também no Gmail no Firefox para Linux durante cerca de uma semana

  • Trabalho no Google Search. Desculpem por isso. Já foi corrigido e também entrou no painel de status da Busca: https://status.search.google.com/incidents/hySMmncEDZ7Xpaf9i32C

    • Felizmente foi reportado no lugar adequado e único onde se consegue suporte do Google: a primeira página do Hacker News
    • Gostaria de ouvir que bug foi esse e como foi corrigido
    • Imagino que, quando algo assim acontece, o estresse seja grande. Software é uma área difícil, e há uma quantidade enorme de coisas que podem dar errado
      Quando se pensa que grandes serviços têm relativamente poucos erros e interrupções, dá para sentir que há muito trabalho por trás disso

  • O Google trabalha com a Mozilla para oferecer uma experiência de busca sem anúncios

    • Por coincidência, acabou virando uma experiência também sem busca

  • O Google está acompanhando este incidente aqui: https://status.search.google.com/incidents/hySMmncEDZ7Xpaf9i32C
    Para deixar claro, trabalho no Google, mas não sou responsável por este caso. Vi esse link no bug do Bugzilla

    • Não entendo por que isso não é simplesmente um rollback. No pior caso, bastaria um commit revertendo a mudança e um novo deploy
      Entendo que o problema tenha ocorrido em um navegador um pouco menos comum, mas parece que a correção em si deveria ser trivial para um engenheiro do Google

  • Para quem enviou: “Use o título original, a menos que ele seja enganoso ou caça-cliques, e não o edite.” — https://news.ycombinator.com/newsguidelines.html
    Se quiser falar algo que considera importante no texto, basta comentar na thread. Assim isso aparece nas mesmas condições que os comentários de outras pessoas: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&sort=byDate&type=comment&query=%22level%20playing%20field%22%20by:dang
    O título enviado era “Google breaks search for Firefox users because of bad UA string sniffing”

  • Isso me lembra um post de blog de um ex-executivo da Mozilla dizendo que o Google causava problemas de propósito para fazer os usuários migrarem para o Chrome
    https://news.ycombinator.com/item?id=38349357

    • Você acha que é isso que aconteceu aqui também? Que o Google deixou a página de busca em branco para enviar usuários do Firefox para o Chrome?
      Ou talvez seja algo mais próximo da navalha de Hanlon

  • https://github.com/webcompat/web-bugs/issues/131916#issuecomment-1882627241
    Este é inteiramente um caso de detecção de UA do lado do servidor feita de forma errada. Ao requisitar com o UA do Firefox Android, você recebe um documento HTML vazio só com o doctype
    É reproduzível com curl, e parece afetar todas as strings de UA com versão 65 ou superior. 64 ou inferiores funcionam

    • É interessante que, se você remove “Android” do UA, vem mais conteúdo; se remove “Mobile”, ainda vem só o doctype; e se remove “Firefox”, o problema é totalmente corrigido

  • Existe alguma razão legítima para usar detecção por string de UA em vez de detecção de recursos? E, afinal, que recursos tão modernos um mecanismo de busca precisa usar para não funcionar em todos os navegadores?

    • Houve alguns casos; o primeiro que me afetou foi quando o Chrome passou a exigir a flag SameSite=None no cabeçalho Set-Cookie em contextos de terceiros[1]

      Aviso: algumas versões antigas do Chrome, Safari e UC browser são incompatíveis com o novo atributo None e podem ignorar ou restringir o cookie
      Por causa dessa restrição, para definir um cookie com funcionamento garantido, a detecção de UA era a única forma confiável
      1: https://web.dev/articles/samesite-cookies-explained

    • Para rastrear usuários de jeitos novos e empolgantes
    • Já vi casos em que navegadores se comportam de maneiras sutilmente diferentes. Enquanto encontrávamos a correção adequada, chegamos a enviar conteúdo diferente por navegador para oferecer a esses usuários uma experiência que funcionasse
      Isso não tem relação com detecção de recursos, então as sugestões comuns não ajudam
    • Talvez para detectar o sistema operacional do usuário e oferecer o link de download do binário correto?
    • Uma coisa que chama atenção na página inicial da Busca Google é que ela é extremamente rápida. Depois da primeira tecla digitada, ela responde em até 200 ms com 10 sugestões contendo texto e imagens, e continua funcionando assim
      Meu tempo de ida e volta até www.google.com é de cerca de 20 ms, então pelo menos 100 ms disso são gastos na internet
      Esse tipo de velocidade não aparece sem otimizações fortes. Na verdade, eu ficaria surpreso se www.google.com não fosse a página mais otimizada da internet
      Por isso, não surpreende nada que ela seja otimizada conforme o navegador que está fazendo a requisição

  • Eu não esperava rir, mas a captura de tela composta só por um retângulo branco puro ficou curiosamente engraçada