- Safari y Firefox distribuyen código que cambia el renderizado y el comportamiento de las API en dominios específicos como TikTok, Netflix e Instagram
- about:compat de Firefox muestra intervenciones por sitio y sus interruptores, además de inyectar CSS y JavaScript personalizados y disfrazar el user agent
- WebKit de Safari lo gestiona como quirks, aplicando soluciones por dominio a problemas de video PiP, alineación de imágenes, popovers y acceso a streaming
- Chrome casi no necesita archivos de excepciones separados, porque la web ya está construida alrededor de Chrome y otros navegadores compensan las diferencias
- Como estas excepciones casi no se reflejan en logs ni en la consola, los desarrolladores deberían probar regularmente en Firefox y Safari y revisar si su sitio aparece en un archivo de quirks
Excepciones por dominio dentro del navegador
- Safari y Firefox distribuyen código que cambia el renderizado o el comportamiento de las API según el dominio que visita el usuario
- Sitios como TikTok, Netflix, Instagram y SeatGuru son objetivos de este tipo de tratamiento por sitio
- Las fuentes relacionadas pueden revisarse públicamente en
Quirks.cpp de WebKit y en las intervenciones de WebCompat de Firefox
- Este código está integrado en el motor de renderizado del navegador de forma que “si es cierto dominio, renderiza distinto” o “si es cierto dominio, maneja distinto las llamadas a la API”
- Chrome prácticamente no necesita archivos de excepciones del mismo tipo, lo que deja ver la asimetría de una web ya construida con Chrome como centro
about:compat de Firefox
- Si escribes
about:compat en la barra de direcciones de Firefox, puedes ver una lista de intervenciones por sitio y sus interruptores
- Cada elemento es una corrección personalizada para un sitio web específico, y si la desactivas puedes ver cómo se rompe el sitio
- El sistema WebCompat de Firefox inyecta CSS y JavaScript personalizados para dominios específicos
- En sitios que detectan mal el navegador, entrega una cadena de user agent modificada
- Estas intervenciones ocultan bugs para que la web no parezca rota, y en Mozilla Bugzilla incluso se rastrean reportes de errores e intentos de contacto con los sitios
Los quirks de Safari
- El motor WebKit de Safari llama a este tipo de tratamiento quirks, y
Quirks.cpp está publicado en GitHub
- En el código de WebKit hay un comentario que dice que Facebook, X y Reddit pausan los
<video> que se desplazan fuera de pantalla sin importar si están o no en modo PiP
- Safari detecta
facebook.com, x.com y reddit.com y cambia el manejo de video en Picture-in-Picture
- Aunque el código de video del sitio esté roto, el navegador no espera a que esas empresas lo corrijan, sino que distribuye una solución alternativa a todos los usuarios
- En un comentario relacionado con SeatGuru aparece
FIXME: Remove this quirk if seatguru decides to adjust their site., lo que muestra que la excepción puede quitarse si el sitio se corrige
- En el historial de commits se han agregado varias correcciones por sitio en los últimos meses
- Problema de centrado de imágenes de planos de planta en Zillow
- Problema por el que TikTok mostraba el mensaje “please upgrade your browser”
- Problema por el que Instagram Reels cambiaba de tamaño de forma irregular durante la reproducción
- Problema por el que el botón “Episodes and Info” de Netflix cerraba mal un popover
- Problema por el que Twitch pausaba video PiP al cambiar de pestaña
- Problema por el que Amazon Prime Video no permitía ver contenido a usuarios de Safari
Una web centrada en Chrome y su asimetría
- Los quirks de WebKit y WebCompat de Firefox no solo corrigen sitios rotos, también compensan una situación en la que Chrome define qué significa que algo “funciona”
- En general, cuando Chrome lanza una función, su dominio de mercado hace que los desarrolladores la usen, y luego otros navegadores implementan esa función o cubren la diferencia con excepciones por sitio
- Para cuando Safari y Firefox alcanzan ese comportamiento, las excepciones ya se han distribuido a millones de usuarios
- WebKit incluye overrides de user agent que hacen que Safari parezca Chrome en páginas de video de Amazon y en varios servicios de streaming
- Como estos sitios detectan si el navegador es Chrome y ofrecen una experiencia degradada a los demás, WebKit engaña sobre la identidad del navegador para proteger a los usuarios de Safari
- Actualmente
Quirks.cpp incluye la siguiente cadena falsa de user agent de Chrome
auto chromeUserAgent = "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36"_s;
- Firefox también actúa de la misma forma, y muchas de las intervenciones en
about:compat consisten en disfrazar el user agent para decirle al sitio “soy Chrome”
- La wiki de Mozilla señala que algunos sitios “bloquean completamente el acceso, muestran un diseño distinto o entregan funcionalidades diferentes” según el resultado de la detección del navegador
- Esta estructura crea un ciclo de retroalimentación
- Los desarrolladores construyen con Chrome como referencia porque Chrome tiene una gran cuota de mercado
- Los sitios funcionan mejor en Chrome
- Los usuarios que encuentran bugs en otros navegadores culpan al navegador y no al sitio
- Los usuarios se pasan a Chrome, y el dominio de Chrome se refuerza aún más
- La razón por la que Chrome casi no necesita un archivo separado de quirks no es que esté mejor diseñado, sino que la web ya está adaptada a Chrome
- En una situación donde los usuarios de navegadores basados en Chromium superan el 80%, los desarrolladores apuntan primero a Chrome
- Si un sitio funciona en Chrome, se publica; si se rompe en Safari o Firefox, ese problema recibe menor prioridad
- Más que agregar excepciones, Chrome marca la agenda
- Si Chrome cambia algún comportamiento, los sitios se actualizan en torno a ese cambio, y los demás navegadores tienen que seguirlo o romperse
La brecha entre la especificación y la web real
- Los ingenieros de navegadores pueden considerar que las especificaciones actuales están bien definidas y que el enfoque de “living specification” de HTML5 redujo el caos de la era de IE/Netscape
- El problema es que los desarrolladores dependen de detalles de implementación que no están en la especificación, y si esos detalles cambian en otros navegadores, se culpa al navegador que “no cumple”
- Cuando la implementación de Chrome se convierte en la referencia a la que todos apuntan, los detalles de comportamiento de Chrome fuera de la especificación pasan a ser la especificación de facto
- Lo mismo ocurrió con Internet Explorer en los 2000: los desarrolladores hacían sitios para IE, otros navegadores se rompían y “funciona en IE” pesaba más que el cumplimiento de estándares
- Antes se esperaba que, si la web respetaba mejor los estándares, los quirks de los navegadores desaparecerían, pero en la práctica no desaparecieron: simplemente se desplazaron a los navegadores que no son Chrome
- Los estándares existen para eliminar el código específico por navegador, pero tras salir de la era de IE se volvió a abrir el mismo hueco, solo que centrado en otros navegadores
- Ahora el código específico por navegador ya no está en el navegador dominante, sino dentro de los navegadores no dominantes que corrigen una web adaptada al navegador dominante
Las excepciones llegan más profundo de lo que parece
- Este tipo de tratamiento no se limita a ajustes visuales simples, sino que cambia el comportamiento base del navegador según el dominio
- Solo la lista de WebKit ya suma miles de líneas e incluye comportamiento de scroll, manejo de eventos táctiles, cálculo del viewport y hasta tratamiento de tipos MIME de imágenes
- Un comentario sobre la función de zoom en imágenes de productos de Amazon dice lo siguiente
When panning on an Amazon product image, we’re either touching on the #magnifierLens element or its previous sibling.
- Safari revisa si el usuario está en Amazon y luego cambia cómo convierte eventos táctiles en eventos de mouse para la función de zoom de producto
- Como el sitio de Amazon asume un comportamiento específico de eventos distinto al comportamiento base de Safari, Safari ofrece ese comportamiento solo para Amazon
- También hay quirks por dominio para storage access, renderizado de barras de desplazamiento, autocorrección y manejo de zoom
- Cada excepción está detrás de una comprobación de dominio y se compila dentro del ejecutable del navegador
Por qué el navegador corrige directamente en vez de esperar
- A veces los fabricantes del navegador contactan al sitio problemático para pedir una corrección, y en el código fuente incluso hay campos con enlaces a esos esfuerzos de outreach
- Pero si un sitio popular funciona en Chrome y se rompe en su navegador, los usuarios culpan al navegador y no al sitio
- Desde la perspectiva del navegador, es más práctico distribuir al día siguiente una solución alternativa de 5 líneas que reportar el bug a un tercero y esperar semanas o meses
- Tampoco siempre está claro a quién contactar
- El desarrollador que escribió el código roto quizá ya no trabaja en la empresa
- El equipo dueño de ese endpoint quizá ni siquiera reconozca la responsabilidad
- El sitio podría estar en modo de mantenimiento y recibir solo parches de seguridad
- Para el navegador, la decisión simple es corregirlo de inmediato, de forma invisible, y reducir así los problemas del usuario
- Un ingeniero de WebKit también escribió sobre el proceso para eliminar un quirk de FlightAware
- FlightAware estaba comparando cadenas de matriz de transform de CSS, y cuando la especificación de CSS cambió la forma de serializar valores, el sitio se rompió al ajustarse el navegador a la especificación
- Los ingenieros añadieron código por dominio que revisaba
flightaware.com, y después de lograr el contacto, FlightAware corrigió su código y el quirk fue eliminado
- Durante esos meses, los usuarios de Safari pudieron tener una experiencia normal gracias a un
if dentro del navegador
Lo que deben revisar los desarrolladores
- Es posible que un sitio web esté recibiendo tratamiento especial de renderizado sin que su equipo lo sepa
- Estos quirks no aparecen en los logs ni muestran en la consola una advertencia del tipo “el navegador está aplicando una solución alternativa a un error”
- Las soluciones alternativas están diseñadas deliberadamente para ser invisibles
- Los sitios que se prueban sobre todo en Chrome corren un riesgo especial
- Puede que la razón por la que el sitio funciona perfectamente no sea que el código sea bueno, sino que el comportamiento de Chrome coincide con las suposiciones del desarrollador
- Otros navegadores quedan entonces ante la disyuntiva de mostrar el sitio roto al usuario o agregarlo a un archivo de quirks
- Hay que abrir el sitio en Firefox y Safari no de vez en cuando, sino de manera regular
- Los archivos de quirks existen porque los desarrolladores no hicieron eso de forma constante
- Si tu dominio aparece en un archivo de quirks, conviene revisar qué parte del sitio está siendo corregida por el navegador
- La web siguió funcionando sin intervención del desarrollador, pero puede que ingenieros de navegadores que no usas hayan estado resolviendo por ti problemas que ni sabías que existían
1 comentarios
Comentarios en Lobste.rs
Detrás de la palabrería de LLM hay una historia interesante
Puede no gustarte el estilo de escritura, y no quiero discutir esa parte, pero que un texto sea malo no significa necesariamente que lo haya escrito una IA. También había frases pésimas antes de la IA
Es una lástima, y ojalá viviéramos en un mundo donde Google no influyera tanto así en la web. El sueño de la “web” era mucho más ambicioso y, en lo personal, inspirador, así que da pena verla como está ahora
El bloque de citas es difícil de leer. Tal vez sea un problema de modo oscuro
Aun así, fue útil que compartieran los detalles de la solución alternativa
La parte de “estos sitios detectan si es Chrome y les dan una experiencia degradada a otros navegadores; así que, en lugar de dejar sufrir a los usuarios de Safari, WebKit miente sobre qué navegador es” parece algo que se repite en toda esta industria
Los fabricantes de computadoras tampoco pocas veces publican firmware ACPI que oculta información a sistemas operativos que no soportan, y al final hacen que esos sistemas operativos engañen al firmware haciéndose pasar por Windows
No me gusta que este artículo se lea como prosa de IA
Además de lo que se menciona aquí, hay dos bucles de retroalimentación. Uno es que Chrome domina, así que los desarrolladores hacen todo pensando en Chrome, entonces funciona mejor en Chrome, y si algo falla en otros navegadores, los usuarios culpan al navegador y se cambian a Chrome
El otro es que un sitio está roto en Firefox, pero aun así el operador del sitio dice que no ve usuarios de Firefox en sus estadísticas. Eso puede pasar incluso si hay tratamiento especial como cambiar el user agent
Si no recuerdo mal, Opera clásico (Presto) fue el primero en empezar a implementar este tipo de capa de compatibilidad
Que la implementación se convierta en la especificación es un problema muy extendido en este campo. En un trabajo anterior usábamos un lenguaje de flujos de trabajo con pruebas de conformidad, con la esperanza de que surgieran varias implementaciones y que el flujo de trabajo fuera portable
El problema central es que hay pocos incentivos económicos para lograr portabilidad completa. Quieres meter funciones extra en tu propia implementación para que la gente siga atada a tu producto
Además, no hay tiempo para crear software por comité, así que quieres adelantarte e incorporar funciones nuevas
La implementación se vuelve la especificación porque vivimos en una sociedad humana
No es nada nuevo. Los navegadores minoritarios siempre han tenido hacks para sitios específicos, y antes el objetivo era IE. La alternativa era simplemente dejar el sitio roto
Hace décadas los desarrolladores web hacían sitios que solo funcionaban en IE y decían “usa IE si quieres usar este sitio”, y ahora lo mismo se está repitiendo con Chrome. No importa si Chrome tiene razón o no. El sitio solo funciona en Chrome, y si otro navegador no garantiza el comportamiento de Chrome en ese sitio, la gente dice “este navegador está roto” y se cambia a Chrome
De verdad me pregunto si la gente cree que Gecko y WebKit deberían dejar estos sitios rotos por una cuestión de principios, o si creen que todos deberían usar solo Chrome y no usar otros navegadores. Esas son las únicas alternativas a los hacks para sitios específicos
Me parece gracioso que Firefox y Safari se hagan pasar por Chrome en el user agent
Pero en la cadena de user agent de Chrome todavía quedan rastros fosilizados de cuando se hacía pasar por un navegador Mozilla y por un navegador de Apple
En esta sola línea de código hay estratos geológicos acumulados: