- Safari e Firefox distribuem código que altera a renderização e o comportamento de APIs em domínios específicos como TikTok, Netflix e Instagram
- O about:compat do Firefox mostra intervenções por site e alternadores, além de injetar CSS·JavaScript personalizados e mascarar o user agent
- O WebKit do Safari gerencia isso como quirks, contornando por domínio problemas de vídeo em PiP, alinhamento de imagens, popovers e acesso a streaming
- O Chrome quase não precisa de arquivos de exceção separados, porque a web já é construída com foco no Chrome, e outros navegadores acabam compensando as diferenças
- Como essas exceções quase não aparecem em logs ou no console, desenvolvedores devem testar regularmente no Firefox e no Safari e verificar se há inclusão em arquivos de quirks
Tratamento de exceções por domínio dentro do navegador
- Safari e Firefox distribuem código que altera a renderização ou o comportamento de APIs conforme o domínio visitado pelo usuário
- Sites como TikTok, Netflix, Instagram e SeatGuru entram nesse tipo de tratamento específico por site
- O código relacionado pode ser visto publicamente em
Quirks.cpp do WebKit e nas WebCompat interventions do Firefox
- Esse código fica no motor de renderização do navegador na forma de regras como “se for um domínio específico, renderize diferente” ou “se for um domínio específico, trate a chamada de API de outro jeito”
- O Chrome praticamente não precisa de arquivos de exceção desse tipo, o que revela a assimetria de uma web já construída em torno do Chrome
O about:compat do Firefox
- Se você digitar
about:compat na barra de endereço do Firefox, verá uma lista de intervenções por site com botões de alternância
- Cada item é um ajuste sob medida para um site específico, e ao desativá-lo dá para ver o site quebrar
- O sistema WebCompat do Firefox injeta CSS e JavaScript personalizados para domínios específicos
- Em sites que detectam o navegador de forma incorreta, ele envia uma string de user agent alterada
- Essas intervenções encobrem bugs para evitar que a web pareça quebrada, e no Mozilla Bugzilla há rastreamento de relatórios de bugs e até tentativas de contato com os sites
Os quirks do Safari
- O mecanismo WebKit do Safari chama esse tratamento de quirks, e o arquivo
Quirks.cpp está disponível no GitHub
- No código do WebKit há um comentário dizendo que Facebook, X e Reddit pausam
<video> rolado para fora da tela, independentemente de o modo PiP estar ativo
- O Safari detecta
facebook.com, x.com e reddit.com e altera o tratamento de vídeo em Picture-in-Picture
- Mesmo quando o código de vídeo do site está quebrado, em vez de esperar que essas empresas corrijam, o navegador distribui um contorno para todos os usuários
- Um comentário relacionado ao SeatGuru diz
FIXME: Remove this quirk if seatguru decides to adjust their site., mostrando que a exceção pode ser removida se o site for corrigido
- O histórico de commits mostra várias correções específicas por site adicionadas nos últimos meses
- problema em que a imagem de planta baixa do Zillow não ficava centralizada
- problema em que o TikTok exibia a mensagem “please upgrade your browser”
- problema em que o Instagram Reels redimensionava de forma irregular durante a reprodução
- problema em que o botão “Episodes and Info” da Netflix fechava popovers incorretamente
- problema em que a Twitch pausava vídeo em PiP ao trocar de aba
- problema em que o Amazon Prime Video não permitia reprodução para usuários do Safari
Web centrada no Chrome e assimetria
- Os quirks do WebKit e o WebCompat do Firefox não apenas corrigem sites quebrados, mas também compensam uma situação em que o Chrome define o que significa “funcionar”
- Em geral, quando o Chrome lança um recurso, desenvolvedores o usam por causa de seu domínio de mercado, e outros navegadores acabam implementando o recurso ou encobrindo a diferença com exceções por site
- Quando Safari e Firefox conseguem alcançar isso, o tratamento excepcional já foi distribuído para milhões de usuários
- O WebKit inclui substituições de user agent que fazem o Safari parecer Chrome em páginas de vídeo da Amazon e em vários serviços de streaming
- Como esses sites detectam se o navegador é o Chrome e oferecem uma experiência degradada a outros navegadores, o WebKit disfarça a identidade do Safari para proteger seus usuários
- Atualmente,
Quirks.cpp contém a seguinte string falsa de user agent do 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;
- O Firefox também funciona desse jeito, e muitas intervenções do
about:compat são mascaramentos de user agent que dizem ao site “eu sou o Chrome”
- A wiki da Mozilla afirma que alguns sites “bloqueiam completamente o acesso, exibem um design diferente ou oferecem recursos diferentes” dependendo do resultado da detecção do navegador
- Essa estrutura cria um ciclo de feedback
- desenvolvedores constroem com base no Chrome porque ele tem alta participação de mercado
- os sites funcionam melhor no Chrome
- usuários que encontram bugs em outros navegadores culpam o navegador, não o site
- usuários migram para o Chrome, reforçando ainda mais seu domínio
- O motivo de o Chrome quase não precisar de um arquivo de quirks separado não é que ele seja melhor projetado, mas que a web já está ajustada para ele
- Em uma situação em que navegadores baseados em Chromium passam de 80% de uso, desenvolvedores tendem a mirar primeiro no Chrome
- Se o site funciona no Chrome, ele vai ao ar; se quebra no Safari ou no Firefox, o problema recebe menor prioridade
- Em vez de adicionar exceções, o Chrome define a agenda
- Quando o Chrome muda algum comportamento, os sites se atualizam para acompanhá-lo, e outros navegadores ou seguem junto ou quebram
A distância entre a especificação e a web real
- Engenheiros de navegadores podem considerar que as especificações atuais estão bem definidas e que a abordagem de “living specification” do HTML5 reduziu a confusão da era IE/Netscape
- O problema é que desenvolvedores dependem de detalhes de implementação que não estão na especificação, e quando esses detalhes diferem em outros navegadores, a culpa recai sobre o navegador “não compatível”
- Quando a implementação do Chrome vira a referência para todos, detalhes de comportamento do Chrome fora da especificação passam a funcionar como especificação de fato
- O mesmo aconteceu nos anos 2000 com o Internet Explorer: desenvolvedores faziam sites para o IE, eles quebravam em outros navegadores, e “funciona no IE” tinha prioridade sobre conformidade com padrões
- No passado, esperava-se que os quirks de navegador desaparecessem à medida que a web seguisse melhor os padrões, mas na prática eles não desapareceram; apenas migraram para os navegadores que não são o Chrome
- Os padrões existiam para eliminar código específico por navegador, mas, depois de sair da era do IE, o mesmo buraco foi recriado em torno de outro navegador
- Agora, o código específico por navegador não está no navegador dominante, e sim nos navegadores não dominantes que compensam uma web ajustada ao navegador dominante
O tratamento de exceções é mais profundo do que parece
- Esse tratamento não se limita a ajustes visuais simples; ele altera o comportamento padrão do navegador conforme o domínio
- Só a lista do WebKit já soma milhares de linhas, incluindo comportamento de rolagem, tratamento de eventos de toque, cálculo de viewport e até tratamento de tipos MIME de imagem
- Um comentário sobre o recurso de zoom nas imagens de produto da Amazon diz o seguinte
When panning on an Amazon product image, we’re either touching on the #magnifierLens element or its previous sibling.
- O Safari verifica se o usuário está na Amazon e então muda a forma como converte eventos de toque em eventos de mouse para o recurso de ampliação do produto
- Como o site da Amazon pressupõe um comportamento específico de eventos, diferente do padrão do Safari, o navegador fornece esse comportamento apenas para a Amazon
- Também existem quirks por domínio para storage access, renderização de barra de rolagem, autocorreção e tratamento de zoom
- Cada exceção fica atrás de uma verificação de domínio e é compilada dentro do executável do navegador
Por que o navegador corrige direto em vez de esperar
- Às vezes, os fabricantes de navegadores entram em contato com sites problemáticos pedindo correções, e no código-fonte há até campos com links para esforços de outreach
- Mas quando um site popular funciona no Chrome e quebra no navegador deles, usuários culpam o navegador, não o site
- Do ponto de vista do navegador, é mais prático distribuir no dia seguinte um contorno de 5 linhas do que abrir um bug para terceiros e esperar semanas ou meses
- Nem sempre está claro com quem entrar em contato
- o desenvolvedor que escreveu o código quebrado pode já ter saído da empresa
- a equipe dona daquele endpoint pode nem reconhecer a responsabilidade
- o site pode estar em modo de manutenção, recebendo apenas patches de segurança
- Para o navegador, a escolha mais simples é corrigir de forma imediata e invisível, reduzindo o problema para o usuário
- Há também um texto de um engenheiro do WebKit sobre o processo de remoção de um quirk do FlightAware
- O FlightAware comparava strings de matriz de transformações CSS, e quando a especificação CSS mudou a forma de serializar valores, o site quebrou assim que o navegador passou a seguir a especificação
- Os engenheiros adicionaram código específico por domínio que verificava
flightaware.com, e depois, com o contato bem-sucedido, o FlightAware corrigiu o código e o quirk foi removido
- Durante aqueles meses, usuários do Safari puderam ter uma experiência normal graças a um
if dentro do navegador
O que desenvolvedores precisam verificar
- Seu site pode estar recebendo tratamento especial de renderização sem que você saiba
- Esse tipo de quirk não aparece nos logs de erro, e o console também não exibe aviso de que “o navegador está contornando um erro”
- O contorno é deliberadamente invisível
- Sites testados principalmente no Chrome correm risco especial
- O motivo de um site funcionar perfeitamente pode não ser um bom código, mas simplesmente o fato de o comportamento do Chrome coincidir com as suposições do desenvolvedor
- Outros navegadores ficam então diante da escolha entre mostrar o site quebrado ao usuário ou adicioná-lo ao arquivo de quirks
- É preciso abrir o site no Firefox e no Safari não ocasionalmente, mas regularmente
- Os arquivos de quirks existem porque desenvolvedores não fizeram isso de forma regular
- Se o seu domínio estiver em um arquivo de quirks, vale revisar o que o navegador precisou contornar
- A web continuou funcionando sem intervenção do desenvolvedor, mas pode ser que engenheiros de navegadores que você não usa tenham resolvido, por você, problemas que você nem sabia que existiam
1 comentários
Opiniões no Lobste.rs
Há uma discussão interessante escondida por trás do blá-blá-blá de LLM
Você pode não gostar do estilo de escrita, e eu nem faço questão de discutir isso, mas um texto ser ruim não significa necessariamente que foi escrito por IA. Já existiam frases horríveis antes da IA
É uma pena, e eu gostaria de viver em um mundo em que o Google não determinasse tanto o rumo da web desse jeito. O sonho da “web” era muito mais ambicioso e, pessoalmente, inspirador, então é triste ver no que isso se tornou
O bloco de citação é difícil de ler. Talvez seja um problema de modo escuro
Foi útil terem compartilhado os detalhes do workaround
A parte de “Esses sites detectam se é o Chrome e oferecem uma experiência degradada para outros navegadores. Então, em vez de deixar usuários do Safari sofrerem, o WebKit mente sobre qual navegador é” parece ser algo que se repete em toda esta indústria
Fabricantes de computadores também não raramente lançam firmware ACPI que esconde informações de sistemas operacionais não suportados, e no fim fazem esses sistemas operacionais fingirem ser o Windows para enganar o firmware
Não gosto do fato de este texto soar como estilo de escrita de IA
Além do que foi dito aqui, existem dois ciclos de feedback. Um é que o Chrome é dominante, então os desenvolvedores fazem tudo pensando no Chrome, aí funciona melhor no Chrome, e quando aparecem problemas em outros navegadores os usuários culpam o navegador em vez do site e migram para o Chrome
O outro é quando um site quebra no Firefox, mas mesmo assim o operador do site diz que não vê usuários de Firefox nas estatísticas. Isso pode acontecer até quando existe tratamento especial como trocar o user agent
Pelo que me lembro, o Opera clássico (Presto) foi o primeiro a começar a implementar esse tipo de camada de compatibilidade
A implementação virar a especificação é um problema muito difundido nesta área. Em um emprego anterior, usamos uma linguagem de workflow com testes de conformidade, esperando que surgissem várias implementações e que os workflows se tornassem portáveis
O problema central é que há pouco incentivo econômico para criar portabilidade completa. Você acaba querendo colocar recursos extras na sua própria implementação para fazer as pessoas continuarem presas ao seu produto
E também não dá para esperar um processo de comitê para fazer software, então você quer sair na frente e colocar os recursos novos antes
A implementação virar especificação acontece porque vivemos em uma sociedade humana
Isso não é novidade. Navegadores minoritários sempre tiveram hacks para sites específicos, e antigamente o alvo era o IE. A alternativa era simplesmente deixar o site quebrado
Décadas atrás, desenvolvedores web faziam sites que só funcionavam no IE e diziam “use IE para usar este site”; agora a mesma coisa está se repetindo com o Chrome. Não importa se o Chrome está certo ou errado. O site só funciona no Chrome, e se outro navegador não garantir o comportamento do Chrome naquele site, as pessoas dizem “esse navegador está quebrado” e migram para o Chrome
O que eu realmente queria saber é se as pessoas acham que Gecko e WebKit deveriam deixar esses sites quebrados por questão de princípio, ou se acham que todo mundo deveria usar só Chrome e não usar outros navegadores. Fora hacks para sites específicos, essas são as únicas duas alternativas
Acho engraçado o Firefox e o Safari fingirem ser o Chrome no user agent
Mas a string de user agent do Chrome ainda carrega vestígios fossilizados de quando ele fingia ser um navegador Mozilla e um navegador da Apple
Há camadas geológicas acumuladas nesta única linha de código: