Publicado em: 6 de maio de 2026
Salvo indicação em contrário, as mudanças a seguir se aplicam à versão mais recente do canal Beta do Chrome para Android, ChromeOS, Linux, macOS e Windows. Saiba mais sobre os recursos listados aqui nos links fornecidos ou na lista em ChromeStatus.com. O Chrome está na versão Beta desde 6 de maio de 2026. Faça o download da versão mais recente em Google.com para computadores ou na Google Play Store no Android.
CSS e interface
Remover a regra de folha de estilo do UA de cor de borda explícita para tabelas
Essa mudança remove a regra CSS border-color: gray incorreta da folha de estilo do UA
para o elemento <table>.
A especificação HTML não contém essa regra, e ela faz com que as bordas não sejam definidas como currentColor por padrão. Nem o Firefox nem o Webkit têm essa regra de cor de borda gray na folha de estilo do UA, o que leva a problemas de interoperabilidade.
Suporte a path() e shape() em shape-outside
Adiciona suporte às funções de forma path() e shape() na propriedade CSS shape-outside. Essas funções permitem que os desenvolvedores definam formas de exclusão de flutuação usando coordenadas de retângulo.
Suporte a rect() e xywh() em shape-outside
Adiciona suporte às funções de forma básica rect() e xywh() na propriedade CSS shape-outside. Essas funções permitem que os desenvolvedores definam formas de exclusão de flutuação usando coordenadas de retângulo, alinhando o Chrome com o Firefox e o Safari, que já oferecem suporte a esse recurso.
Cor de destaque do sistema de escopo do app da Web
Restringe o acesso à cor de destaque do sistema para palavras-chave CSS e accent-color: auto apenas a um app da Web e ao contexto do perfil inicial.
As palavras-chave CSS AccentColor e AccentColorText representam um vetor de impressão digital
significativo ao expor as cores do sistema do usuário na Web. Portanto, elas só estão disponíveis em contextos de apps da Web instalados. Os controles de formulário com accent-color: auto também correspondem a esse escopo com o lançamento desse recurso. Isso introduz expectativas mais consistentes de desenvolvedores e usuários para cores do sistema e se alinha às restrições de impressão digital para AccentColor[Text].
Cortar o estouro de texto na interação do usuário
Quando um usuário interage (editando ou navegando com o cursor de texto) com um texto que tem text-overflow: ellipsis definido, o texto muda temporariamente de reticências para clipe, permitindo que o usuário veja e interaja com o conteúdo de estouro oculto.
Esse recurso se aplica a todos os elementos editáveis e não editáveis. Para controles de formulário (textarea, input), o comportamento já é compatível.
Decorações de lacuna CSS
As decorações de lacuna CSS permitem estilizar lacunas em layouts de contêiner, como grade e flexbox, de maneira semelhante a column-rule em layouts de várias colunas. Esse recurso é muito solicitado por desenvolvedores da Web que precisam usar hacks para estilizar as lacunas em layouts de grade e flexbox.
image-rendering: crisp-edges
image-rendering: crisp-edges indica que a imagem precisa ser dimensionada de forma a preservar o contraste e as bordas, evitando cores suaves ou introduzindo desfoque na imagem durante o processo.
Limite da camada superior da pseudoclasse de ação do usuário
Esse recurso representa o comportamento descrito na
especificação CSS Selectors Level 4,
que afirma que :hover, :active e :focus-within correspondem aos pais
dos elementos, mas apenas até o primeiro elemento da camada superior na cadeia pai.
A mudança para o Chromium implementa essa restrição para elementos da camada superior.
Concretamente, isso significa que, na estrutura a seguir, se o usuário passar o cursor sobre o <button>,
a pseudoclasse :hover vai corresponder ao <button> e ao pop-up, mas
não ao elemento <main>.
<main>
<div popover>
<button></button>
</div>
</main>
<script>document.querySelector('[popover]').showPopover();</script>
A lógica por trás dessa mudança é que, normalmente, os elementos da camada superior são renderizados "em outro lugar", em um local visualmente desconectado do elemento pai. Portanto, normalmente não faz sentido mudar os estilos do elemento pai quando o elemento da camada superior é ativado ou ativado, por exemplo.
A implementação de seleção personalizável enviada no Chromium tem essa lógica codificada para o caso específico do pop-up de seleção ::picker(). Essa lógica de caso especial está sendo removida em favor do comportamento mais geral com esse recurso.
Suporte a path-length como uma propriedade CSS
Essa mudança introduz uma nova propriedade CSS, path-length, que é mapeada para o atributo de apresentação pathLength do SVG. Ela se aplica a elementos de geometria SVG
que oferecem suporte a pathLength (incluindo <path>, <circle>, <rect>,
<line>, <polyline>, <polygon> e <ellipse>).
A exposição de pathLength como uma propriedade CSS permite que os autores a especifiquem em folhas de estilo, estilos inline e animações, permitindo que ela participe de cascata, especificidade, transições e animações CSS normais. A propriedade afeta todos os cálculos que dependem do tamanho total do caminho, incluindo a renderização de traços e o posicionamento de texto ao longo de um <textPath>.
As declarações CSS substituem o atributo de apresentação seguindo as regras de precedência CSS padrão. O valor inicial de path-length é none, que representa a ausência de um tamanho do caminho fornecido pelo autor e é diferente de um valor numérico explícito, como 0.
O comportamento somente de atributo atual é preservado quando o recurso está desativado.
APIs Web
Intl.Locale.prototype.variants
Adicione Intl.Locale.prototype.variants conforme declarado em
proposta TC39 e também aceite
"variantes" no pacote de opções no construtor Intl.Locale como em
atualização do ID de idioma TC39. As mudanças no ECMA402 são mescladas
em solicitação de pull 960 e o código de teste no test262 é
mesclado em solicitação de pull 4474
Promessas de rolagem programática
Atualmente, os desenvolvedores da Web não têm como saber quando uma rolagem suave programática foi concluída. Esse recurso oferece uma solução para o problema: fazer com que os métodos de rolagem programática retornem objetos de promessa que são resolvidos na conclusão da rolagem com o status de interrupção.
Solicitação de pagamento: permitir que os gerenciadores de pagamento informem erros internos
Permite que os gerenciadores de pagamento acessados com a API Payment Request retornem erros distintos para "usuário cancelado" em comparação com "erro interno do app de pagamento". Isso permite que os desenvolvedores da Web criem fluxos melhores para os usuários, por exemplo, tentando novamente ou voltando a um fluxo diferente quando ocorre um erro interno do app, interrompendo corretamente o fluxo se o usuário quiser cancelar.
A API Payment Handler baseada na Web pode indicar essa diferença com base no erro usado para rejeitar a promessa transmitida para PaymentRequestEvent.respondWith.
Se a promessa for rejeitada com um OperationError, o "erro interno do app" (OperationError) será retornado ao comerciante usando o método PaymentRequest.show(). Caso contrário, o "cancelamento do usuário" (AbortError) será retornado.
A infraestrutura do gerenciador de pagamentos de apps nativos também é atualizada de maneira semelhante, mas está fora do escopo das APIs da Web.
Respeitar autocorrect="off" para o teclado touchscreen do Windows no TSF
O atributo HTML autocorrect permite que os autores da Web controlem se
a autocorreção deve ser aplicada à entrada do usuário em elementos editáveis, incluindo
<input>, <textarea>, e hosts contenteditable. No Windows, o teclado touchscreen ignora esse atributo e sempre corrige palavras. Por exemplo,
digitar "truf" seguido de espaço em um elemento com autocorrect="off" produz
"true " em vez de preservar "truf ". Esse recurso faz com que a integração do TSF
do Chrome detecte e reverta as autocorreções do teclado touchscreen quando o elemento editável focado
tiver autocorrect="off" definido.
Desconectar WebSockets na entrada do bfcache
As conexões WebSocket ativas não impedem mais que uma página entre no cache de avanço e retorno (bfcache, na sigla em inglês). Ao fechar as conexões na entrada do bfcache em vez de marcar o documento como inelegível, o navegador permite que páginas com websockets ativos sejam armazenadas e restauradas.
Atributo Request.isReloadNavigation
Adiciona o atributo booleano somente leitura isReloadNavigation à interface de solicitação da API Fetch. Esse atributo indica se a solicitação de navegação atual foi iniciada como uma recarga acionada pelo usuário (por exemplo, usando o botão de atualização, location.reload() ou history.go(0)). Esse sinal é exposto principalmente no objeto de solicitação em um FetchEvent do service worker.
Desativar filtros SVG em plug-ins e iframes de origem cruzada e restritos
Esse lançamento impede que os filtros SVG sejam aplicados a iframes de origem cruzada ou restritos (por exemplo, iframes em sandbox) e plug-ins incorporados (por exemplo, PDFs). Quando um frame ou plug-in é pintado com um efeito de filtro SVG, a árvore de efeitos é percorrida para encontrar o ancestral mais alto sem filtros SVG, e esse efeito é aplicado.
Novos testes de origem
No Chrome 149, você pode ativar os seguintes novos testes de origem.
Política de permissões: focus-without-user-activation
Oferece aos incorporadores controle sobre o foco programático de conteúdo incorporado com a política de permissões focus-without-user-activation. Quando a política é negada para um frame, as chamadas de foco programático (element.focus(), autofocus, window.focus(), dialog.showModal() e foco de pop-up) são bloqueadas, a menos que sejam acionadas pela ativação do usuário. O foco iniciado pelo usuário, como clicar ou usar a tecla Tab, nunca é afetado.
A política pode ser definida usando um cabeçalho de resposta HTTP Permissions-Policy ou o atributo allow do iframe. A delegação de foco é compatível: um frame pai que tem foco pode transmitir o foco programaticamente para um iframe filho, mesmo que o filho tenha a política negada. Depois que um frame tem foco, ele pode mover o foco na própria subárvore.
API de entrada orientada a eventos do gamepad
Essa proposta estende a API Gamepad com um novo modelo orientado a eventos que permite que os aplicativos recebam entrada do gamepad com menor latência. Em vez de depender de pesquisas frequentes usando navigator.getGamepads(), os desenvolvedores agora podem detectar um evento rawgamepadinputchange, que é acionado sempre que novos dados de entrada estão disponíveis no dispositivo. Isso permite um processamento de entrada mais responsivo, principalmente em aplicativos sensíveis à latência.
Descritores personalizados do WebAssembly
Permite que o WebAssembly armazene dados associados a tipos de origem de maneira mais eficiente em novos objetos de descritor personalizado. Esses descritores personalizados podem ser configurados com protótipos para os objetos WebAssembly desse tipo de origem. Isso permite que os métodos sejam instalados na cadeia de protótipos de um objeto WebAssembly e chamados diretamente do JavaScript usando a sintaxe normal de chamada de método. Os protótipos e métodos podem ser configurados de forma declarativa usando uma função integrada importada.