Página en blanco al acceder a www.google.com

 (github.com/webcompat)
1 puntos por GN⁺ 2024-01-10 | 1 comentarios | Compartir por WhatsApp
  • Se registró un issue de webcompat en Firefox Mobile 121.0 para Android donde, al acceder a https://www.google.com/, la página se muestra en blanco y no se pueden usar las funciones principales de la Búsqueda de Google
  • En las pruebas de reproducción, el mismo problema ocurrió tanto en Firefox Release 121.0.1 como en Firefox Nightly 123.0a1, y no se reprodujo en Chrome 120.0.6099.43
  • Al desactivar ETP, aparece el banner de cookies, pero incluso después de aceptar, el cuerpo de la página sigue quedando en blanco, por lo que el problema no se resuelve
  • El issue relacionado en Mozilla Bugzilla quedó vinculado como 1873601, y había un parche listo para distribuirse como dot-release si era necesario
  • Posteriormente, Google comenzó a desplegar una corrección y, tras observar la situación durante algunas horas, se consideró que el problema parecía resuelto para la gran mayoría de los usuarios, por lo que se decidió cerrar el issue como fixed

Problema ocurrido y entorno del primer reporte

  • La URL objetivo es https://www.google.com/ y el tipo de problema se registró como Site is not usable
  • El síntoma reportado fue que la página de Google no cargaba correctamente y se mostraba como una pantalla en blanco
  • Entorno del primer reporte:
    • Navegador: Firefox Mobile 121.0
    • Sistema operativo: Android 13
    • Prueba con otro navegador: Yes Other
  • La configuración del navegador incluía los siguientes 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

Resultados de reproducción y navegador de comparación

  • La persona encargada de reproducir el problema pudo reproducirlo
  • Entorno de prueba:
    • Firefox Nightly 123.0a1-20240108213208
    • Firefox Release 121.0.1-20231230165955
    • Chrome 120.0.6099.43
    • Dispositivo: OnePlus 6 A6000
    • Sistema operativo: Android 11
    • Pantalla: 1080 x 2280, 19:9, aprox. 402 ppi
  • Resultados de reproducción:
    • Se reprodujo tanto en Firefox Release como en Nightly
    • No se reprodujo en Chrome
  • El issue se clasificó en las categorías Firefox Mobile, motor Gecko y fallo de carga de página

Prueba con ETP desactivado

  • Al desactivar ETP, aparece el banner de cookies
  • Incluso tras aceptar el banner de cookies, el cuerpo de la página de Google no se muestra y sigue quedando como pantalla en blanco
  • Solo con el resultado de esta prueba, desactivar ETP no constituye una solución al problema

Diagnóstico e issues relacionados

  • El issue pasó a la etapa needsdiagnosis
  • El bug relacionado en Mozilla Bugzilla fue referenciado de forma cruzada como 1873601
  • Ese mismo día se vincularon varios issues similares relacionados con Google:

Avance de la corrección y enfoque de gestión

  • La persona responsable indicó que había un parche listo para distribuirse como dot-release si era necesario
  • En ese momento se consideró que posiblemente ese parche no sería necesario
  • Más tarde, Google comenzó a desplegar una corrección y, tras observar el avance durante algunas horas, el problema parecía resuelto para la gran mayoría de los usuarios
  • La conversación quedó desbloqueada para los usuarios restantes que siguieran experimentando la pantalla en blanco en Google Search y pudieran resolverlo con UA spoof
  • Si el mismo síntoma continúa, registrar un bug nuevo puede ser más fácil de detectar en el proceso de triage que dejar un comentario en el issue existente

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-01-10
Opiniones de Hacker News

  • El punto clave es que, como se ve en https://github.com/webcompat/web-bugs/issues/131916#issuecomment-1882627241, se trata de un caso en el que la detección de UA del lado del servidor está completamente mal
    Si se hace la solicitud con el UA de Firefox Android, se recibe un documento HTML vacío que solo contiene el doctype, y también se puede reproducir con curl
    $ curl -H "User-Agent: Mozilla/5.0 (Android 10; Mobile; rv:123.0) Gecko/123.0 Firefox/123.0" https://www.google.com
    Parece que todas las cadenas de UA con versión 65 o superior están afectadas, y las de 64 o inferior funcionan

    • Para ser exactos, es Firefox Mobile
      La cadena de UA que Firefox Mobile envía en modo escritorio recibió una respuesta normal
    • Hace unas semanas también vi este fenómeno en Gmail con Firefox en Linux durante una semana

  • Trabajo en Google Search. Perdón por esto. Ya quedó corregido y también se publicó en el panel de estado de búsqueda: https://status.search.google.com/incidents/hySMmncEDZ7Xpaf9i32C

    • Por suerte se reportó en el lugar adecuado y único para recibir soporte de Google: la portada de Hacker News
    • Me gustaría saber qué bug fue y cómo lo arreglaron
    • Cuando pasan cosas así debe ser muy estresante. El software es un campo difícil, y hay una cantidad enorme de cosas que pueden salir mal
      Cuando pienso en que los grandes servicios tienen relativamente pocos errores e interrupciones, me doy cuenta de la cantidad de trabajo que hay detrás

  • Google colabora con Mozilla para ofrecer una experiencia de búsqueda sin anuncios

    • Por coincidencia, también terminó siendo una experiencia sin búsqueda

  • Google está siguiendo este incidente aquí: https://status.search.google.com/incidents/hySMmncEDZ7Xpaf9i32C
    Para ser transparente, trabajo en Google, pero no estoy a cargo de este caso. Vi este enlace en el bug de Bugzilla

    • No entiendo por qué esto no es simplemente un rollback. En el peor de los casos, bastaría con un commit de reversión y redesplegar
      Entiendo que el problema haya aparecido en un navegador un poco menos común, pero para un ingeniero de Google la corrección en sí debería ser trivial, ¿no?

  • Para quien lo envió: “Use el título original, a menos que sea engañoso o sensacionalista; no lo edite”. — https://news.ycombinator.com/newsguidelines.html
    Si quiere decir algo que considera importante sobre el artículo, puede dejarlo como comentario en el hilo. Así aparecerá en las mismas condiciones que los demás: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&sort=byDate&type=comment&query=%22level%20playing%20field%22%20by:dang
    El título enviado era “Google breaks search for Firefox users because of bad UA string sniffing”

  • Esto me recuerda a una publicación de blog de una exdirectiva de Mozilla que escribió que Google causaba problemas a propósito para hacer que los usuarios se pasaran a Chrome
    https://news.ycombinator.com/item?id=38349357

    • ¿La idea es que aquí también pasó eso? ¿Que Google dejó la página de búsqueda en blanco para enviar a los usuarios de Firefox a Chrome?
      O quizá sea algo más cercano a la navaja de Hanlon

  • https://github.com/webcompat/web-bugs/issues/131916#issuecomment-1882627241
    Este es un caso enteramente de detección de UA del lado del servidor hecha mal. Si se solicita con el UA de Firefox Android, se recibe un documento HTML vacío que solo contiene el doctype
    Se puede reproducir con curl, y parece afectar a todas las cadenas de UA con versión 65 o superior. 64 o inferior funciona

    • Es interesante que, si se quita “Android” del UA, llega más contenido; si se quita “Mobile”, todavía llega solo el doctype; y si se quita “Firefox”, se arregla por completo

  • ¿Hay alguna razón válida para usar detección de cadena de UA en vez de detección de funcionalidades? ¿Y cuántas funciones modernas necesita usar un motor de búsqueda para que no pueda funcionar en todos los navegadores?

    • Hubo algunos casos; el primero que me afectó fue cuando Chrome cambió para exigir la bandera SameSite=None en el encabezado Set-Cookie en contextos de terceros[1]

      Advertencia: algunas versiones antiguas de Chrome, Safari y UC browser son incompatibles con el nuevo atributo None y pueden ignorar o restringir las cookies
      Debido a esta restricción, la detección de UA era la única forma confiable de establecer cookies cuyo funcionamiento estuviera garantizado
      1: https://web.dev/articles/samesite-cookies-explained

    • Para rastrear a los usuarios de formas nuevas y emocionantes
    • He visto casos en los que los navegadores se comportan de manera sutilmente distinta. Mientras encontrábamos la corrección correcta, para reducir el impacto llegamos a entregar contenido distinto según el navegador y así darles a esos usuarios una experiencia que funcionara
      Esto no tiene relación con la detección de funcionalidades, así que las sugerencias habituales no sirven
    • ¿Para detectar el sistema operativo del usuario y ofrecer el enlace correcto de descarga del binario?
    • Algo notable de la página principal de Google Search es que es increíblemente rápida. Después de la primera pulsación de tecla, responde en menos de 200 ms con 10 sugerencias que incluyen texto e imágenes, y sigue funcionando así
      Mi tiempo de ida y vuelta a www.google.com es de unos 20 ms, así que al menos 100 ms de eso se consumen en Internet
      Esa velocidad no se logra sin una optimización fuerte. De hecho, me sorprendería si www.google.com no fuera la página más optimizada de Internet
      Por eso no me sorprende en absoluto que optimicen según qué navegador haga la solicitud

  • No esperaba reírme, pero la captura de pantalla con solo un rectángulo blanco puro me pareció extrañamente graciosa