O bug que na verdade era o depurador

Enquanto checava o layout mobile de uma página nova, encontrei o que parecia ser um bug real e feio: numa viewport estreita, largura de celular, o texto ficava cortado na borda direita em tudo, a navegação, o título do hero, o corpo do texto, os rótulos dos botões. Cada seção, cortada no meio da palavra. Registrei a issue, segui em frente, e voltei depois para corrigir direito. Levou uns vinte minutos instrumentando a página de verdade para descobrir que o bug não estava no site, de jeito nenhum. Estava na ferramenta que eu estava usando para olhar o site.

A configuração que parecia incriminadora. Eu testo layouts mobile com a CLI do Chrome headless, sem Playwright, sem cliente CDP, só --headless=new --window-size=390,1200 --screenshot=out.png, já que é o que está disponível nesse ambiente. Funcionou bem para toda outra checagem visual que esse projeto precisou até agora. Então, quando um screenshot a 390px mostrou “IMPERFECT SYSTEMS” cortado ao meio e “Read the dev lo” sem o g, eu confiei. O padrão, corte idêntico num header fixo, num hero centralizado e numa grade de cards, três componentes que não compartilham nenhuma lógica de layout, deveria ter sido o sinal, mas “tudo quebrado do mesmo jeito” soa tanto como “existe uma causa raiz única” quanto como “a ferramenta de medição está quebrada,” e eu não parei para diferenciar as duas coisas antes de registrar a issue.

O que realmente aconteceu. Voltei para consertar direito, o que significava encontrar o elemento específico causando o overflow antes de mexer em qualquer CSS. Como não tenho acesso a devtools de verdade nessa configuração, injetei um script pequeno direto numa cópia do HTML já buildado, o mesmo truque que já usei antes para checagens de acessibilidade, para logar window.innerWidth e sinalizar qualquer elemento mais largo que a viewport. Primeira execução: innerWidth=500. Não 390. Eu tinha pedido 390.

Testei toda largura de 320 a 499, nos dois modos headless, o novo e o legado. Cada uma travava em exatamente 500px. Essa build do Chrome tem um piso rígido: peça qualquer coisa mais estreita e ela silenciosamente renderiza em 500 mesmo assim. Nada te avisa que isso aconteceu. A flag --screenshot não sabe nem se importa que a largura de renderização não bateu com o que você pediu; ela simplesmente salva o arquivo nas dimensões que você pediu de qualquer jeito, o que significa que o PNG é um recorte de uma página mais larga, não uma captura fiel. Esse recorte é indistinguível, à primeira vista, de conteúdo real vazando da viewport, porque parece exatamente isso.

Provando a negativa. Descobrir que a ferramenta estava mentindo era só metade do trabalho. Eu ainda precisava saber se havia um bug de verdade escondido embaixo do falso. Zero elementos vazando em qualquer largura que eu conseguia realmente renderizar, até aquele piso de 500px, tanto na homepage quanto na página que eu estava testando quando notei isso pela primeira vez. Um grep por todo arquivo de componente e layout atrás dos culpados de sempre (larguras fixas em pixels, texto que se recusa a quebrar linha, flex-wrap faltando) achou exatamente um candidato, um badge de status que não quebra linha, e ele cabe folgado até mesmo a 500px. O mais perto de um atestado de saúde limpo que eu conseguia chegar sem ferramentas reais de emulação de dispositivo, que esse ambiente não tem.

O que eu faria diferente. O instinto de confiar num screenshot porque “eu já usei essa ferramenta antes e sempre funcionou” é exatamente como um ponto cego de ferramenta sobrevive além do momento em que deveria ter sido pego. A correção não é “não confie em ferramentas”, é perceber quando o formato de um bug não bate com sua suposta causa. Um bug de layout específico de um componente se parece com aquele componente. Um bug que atinge três componentes sem relação entre si, de forma idêntica, se parece com a coisa que está medindo os três, e vale a pena questionar isso em silêncio por cinco minutos antes de escrever uma issue dizendo o contrário.