O Safari 27 Já Está no Celular dos Seus Usuários. O Que Mudou nos Bugs Que Eles Reportam

O Safari 27 foi lançado em 14 de setembro de 2026, junto com o iOS 27, o iPadOS 27 e o macOS 27. As notas de lançamento da Apple trazem uma linha que importa mais do que parece: o mesmo Safari também chega ao macOS 26 e ao macOS Sequoia. Ou seja, ele não fica restrito a quem atualizou para o novo sistema operacional. Alcança qualquer pessoa que aceite uma atualização do Safari em um Mac de dois anos, e todo iPhone que se atualiza sozinho durante a noite, ou seja, a maioria deles.

Até o fim da semana, boa parte das pessoas que acessam seu site pelo iPhone estará usando um navegador diferente daquele que usavam na sexta-feira, e quase nenhuma delas vai perceber isso. É isso que transforma o lançamento de um navegador em um evento de bug report. A página não mudou. Os relatos sobre ela, sim.

O anúncio da beta na WWDC colocou o tamanho do lançamento em 58 novos recursos, 525 correções e 4 descontinuações. A maioria delas é invisível para quem não escreve CSS. Um punhado muda o comportamento de uma página de um jeito que o usuário percebe, e são essas que chegam como tickets. Aqui estão elas, com o que fazer em cada caso.

A ancoragem de rolagem está ativa, e ela desloca um bug em vez de eliminá-lo

Por anos, o Safari foi o navegador em que a página pulava. Uma imagem terminava de carregar acima do parágrafo que você estava lendo, ou um banner se injetava lá no topo, e tudo descia debaixo do seu dedo. Chrome e Firefox compensam isso há anos; agora o Safari também compensa. Quando um conteúdo é inserido ou removido acima da viewport, o navegador ajusta a posição de rolagem para que o que você estava lendo continue no mesmo lugar.

Isso fecha uma família inteira de relatos do tipo “a página pula enquanto estou lendo”, mas só para quem está no Safari 27. Quem ainda está no Safari 26 vai continuar reportando isso, e esse já é o primeiro motivo pelo qual a versão importa no ticket.

O segundo motivo é a armadilha. Muitos sites já lutavam contra esse pulo por conta própria: mediam a altura do que estava prestes a carregar e deslocavam a posição de rolagem nessa mesma medida quando o conteúdo chegava. Esse código estava correto na sexta-feira. Hoje, no Safari 27, o navegador faz a mesma correção primeiro, e a correção do site vem por cima dela. Agora a página pula na direção contrária, exatamente na medida que o site costumava corrigir. Um relato que diz “a página pula para cima quando as imagens carregam, isso nunca aconteceu antes” é esse bug, e a resposta honesta é que a correção do site agora é a causa.

A saída padrão é a mesma em todos os navegadores: overflow-anchor: none no container desliga a ancoragem do navegador para essa região, de modo que só a compensação do próprio site continua rodando. Ou, melhor ainda, apague a compensação e deixe as três engines cuidarem disso.

A mesma seção das notas corrige algo mais específico que gerava um formato de relato bem confuso no iOS: chamar scrollTo durante uma rolagem com momentum costumava interromper a rolagem na hora. Uma página que rolava o usuário para algum lugar e depois dava a impressão de ter “travado” a tela geralmente era esse o problema. Corrigido na 27, presente na 26.

Oito correções de Content Security Policy, e duas delas geram relatos

A seção de segurança das notas de lançamento lista oito correções de Content Security Policy. Seis delas tornam o Safari mais rígido ou mais correto, de um jeito que afeta sobretudo páginas que já estavam um pouco erradas. Duas delas vão aparecer em um endpoint de relatos sem nenhuma mudança do seu lado.

Violações de frame-ancestors em uma política report-only estavam sendo descartadas em vez de reportadas. Agora elas são enviadas. Um site rodando Content-Security-Policy-Report-Only com frame-ancestors, que é como a maioria das equipes descobre quem está incorporando o site antes de aplicar qualquer bloqueio, estava cego para o Safari desde que essa política existe. A partir desta semana, os relatos chegam. O volume pode parecer um ataque. É um acúmulo represado.

Importações de módulos JSON (import data from "./x.json" with { type: "json" }) estavam sendo verificadas contra script-src. A especificação diz connect-src, e agora o Safari 27 concorda. Uma política que liberava a origem do JSON em script-src mas não em connect-src passa a bloquear essas importações, e uma política que fazia o contrário passa a permiti-las. De qualquer forma, o comportamento da página muda em uma versão do navegador e não na anterior.

Fraco

Nosso endpoint de relatos de CSP encheu da noite para o dia. Alguma coisa está nos incorporando em todo lugar.

Melhor

Violações de frame-ancestors report-only do Safari 27.0 começaram a chegar em 15 de setembro. O Safari 26 as descartava, então isso é a incorporação que já existia e não conseguíamos ver, não uma incorporação nova.

Mais duas da mesma lista merecem uma frase, porque transformam uma página quebrada em uma página que funciona, e isso também é uma mudança que alguém vai notar. Elementos <object> que carregam imagens estavam sendo bloqueados por img-src e agora não são mais. E 'self' não correspondia a origens de script em documentos com origem opaca, como um iframe em sandbox, então alguns scripts que deveriam ter rodado não rodavam. Ambos corrigidos. Se uma página começou a funcionar misteriosamente no celular de alguém nesta semana, talvez não tenha sido o seu deploy.

Selects estilizados que antes eram simples

appearance: base-select chega no Safari 27, junto com o elemento <selectedcontent>. Qualquer site que já tinha lançado um <select> personalizado para o Chrome, protegido por feature detection, agora recebe a versão personalizada no Safari também. Esse é o resultado esperado e geralmente é bom. Também é a primeira vez que esse CSS roda no Safari, e a primeira vez que alguém o vê em um iPhone na largura real, com o teclado real, no modo escuro real. Espere algum relato esporádico, e trate “o dropdown está diferente no meu celular desde ontem” como algo preciso, e não como confusão.

Cookies Secure no localhost

Escondido na seção de Networking: agora o Safari respeita cookies Secure em hosts loopback. Todas as outras engines fazem isso há anos, e é por isso que um fluxo de login podia funcionar no Chrome em localhost, falhar só no Safari, e fazer alguém perder uma hora verificando certificados. Essa hora específica agora acabou. O que o localhost realmente é cobre o resto do motivo pelo qual “funciona no localhost” prova menos do que parece.

O que tudo isso significa para o relato

Todos os itens acima têm o mesmo formato: a mesma página, se comportando de um jeito no Safari 26.6 e de outro no Safari 27.0, no mesmo dia, para duas pessoas sentadas lado a lado. Esse formato só é diagnosticável se o relato disser de qual versão ele veio.

A maioria dos relatos não diz. “Safari no meu iPhone” é o que as pessoas escrevem, e a culpa não é delas: no iPhone, a versão do Safari é a versão do iOS, fica em Ajustes, em Geral e depois em Sobre, e a atualização aconteceu enquanto elas dormiam. Então a primeira pergunta a fazer de volta tem que ser a versão, antes dos passos, e o jeito mais barato de consegui-la é uma página que a lê sozinha. A nossa fica em /tools/user-agent: ela mostra o navegador e a versão, o sistema operacional, o tamanho da tela e o esquema de cores, e quem está reportando pode colar tudo isso de uma vez. Funciona em qualquer navegador, porque precisa funcionar.

Uma limitação honesta do nosso lado. Session Replay é uma extensão para Chrome. Ela não consegue capturar um relato a partir do Safari, e um bug que só acontece no Safari 27 não vai aparecer em uma página aberta no Chrome. O que ela faz é resolver rápido a outra metade da questão: abra a mesma página no Chrome, capture, e em menos de um minuto você sabe se a falha está na página ou no engine. É isso, na prática, o essencial dos testes cross-browser: três engines, e saber qual delas você está olhando.

Para a parte do Safari, se você tem um Mac, o Web Inspector via cabo ainda é o caminho, e como inspecionar elemento no iPhone mostra o passo a passo. O Web Inspector do Safari 27 agora mostra cada requisição de uma cadeia de redirecionamento individualmente, o que é um pequeno alívio quando o bug é um loop de login.

O restante do lançamento, resumidamente

Mais algumas coisas nas notas que um desenvolvedor vai querer saber que existem.

Ficou mais fácil consumir streams. for await...of sobre um ReadableStream, ReadableStream.from() para construir um a partir de qualquer iterável, e streams agora podem ser transferidas via postMessage(). Código escrito para o Chrome que dependia de qualquer um desses recursos agora roda no Safari sem precisar de polyfill.

Erros de extensões web agora são reportados. Exceções não capturadas e rejeições de promise não tratadas nos scripts de uma extensão web do Safari agora aparecem, quando antes simplesmente desapareciam. Se você mantém uma versão para Safari de uma extensão do Chrome, prepare-se para descobrir erros que ela já tinha há algum tempo.

A API de roteamento estático de service worker chegou, e permite que um service worker declare de antemão quais requisições passam direto por ele, sem esperar, de modo que o caminho de rede de um asset estático não precisa mais esperar o worker inicializar.

Quatro remoções de SVG. SVGLocatable, SVGTransformable, nearestViewportElement, farthestViewportElement e viewTarget desapareceram, junto com glyph-orientation-horizontal. Ferramentas antigas de SVG que usavam qualquer um desses vão lançar erro no Safari 27 e não no 26, o que é mais um relato específico de versão para reconhecer.

O que levar disso

Uma atualização de navegador é uma mudança em produção que ninguém da equipe fez o deploy, revisou ou consegue reverter, e ela chega a uma fração diferente dos usuários a cada dia, durante uma semana. A única defesa é saber de qual versão cada relato veio, para que “começou ontem” possa ser associado a “o Safari 27 foi lançado ontem” em vez de ao último deploy.

As próprias notas da Apple são a referência, e são longas: Notas de lançamento do Safari 27.