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. Baixe a versão mais recente em Google.com para computador ou na Google Play Store para Android.
CSS e interface
Remover regra explícita de folha de estilo do UA de cor da borda para tabelas
Essa mudança remove a regra CSS border-color: gray errônea da folha de estilo do UA para o elemento <table>.
A especificação HTML não contém essa regra, o que 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 causa problemas de interoperabilidade.
Apoie path() e shape() em shape-outside
Adiciona suporte às funções de forma path() e shape() na propriedade shape-outside do CSS.
Essas funções permitem que os desenvolvedores definam a forma de shape-outside de maneira mais flexível e oferecem suporte à animação.
Atualizado em 7 de junho de 2026 para corrigir a descrição, que antes se referia ao uso de coordenadas de retângulo.
Apoie rect() e xywh() em shape-outside
Adiciona suporte às funções de forma básica rect() e xywh() na propriedade shape-outside do CSS. Essas funções permitem que os desenvolvedores definam formas de exclusão de ponto flutuante usando coordenadas de retângulo, alinhando o Chrome ao Firefox e ao Safari, que já oferecem suporte a esse recurso.
Cor de destaque do sistema no escopo do app da Web
Restringe o acesso à cor de destaque do sistema para palavras-chave CSS e
accent-color: auto para ficar apenas em um app da Web e no contexto do perfil inicial.
As palavras-chave AccentColor e AccentColorText do CSS representam um vetor significativo de impressão digital
ao expor as cores do sistema do usuário na Web. Por isso,
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 texto excedente na interação do usuário
Quando um usuário interage (edição ou navegação com cursor) com um texto que tem text-overflow: ellipsis definido, o texto muda temporariamente de reticências para corte, permitindo que o usuário veja e interaja com o conteúdo oculto de estouro. 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 do CSS
Com as decorações de lacuna do CSS, é possível estilizar lacunas em layouts de contêiner, como grade e
flexbox, 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 hoje.
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 o suavização das cores ou a introdução de 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 de nível 4 dos seletores de CSS,
que afirma que :hover, :active e :focus-within correspondem aos elementos pais,
mas apenas até o primeiro elemento da camada superior na cadeia de elementos pais.
A mudança no Chromium implementa essa restrição para elementos da camada superior.
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 popover, mas
não vai corresponder 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, geralmente não faz sentido mudar os estilos do elemento pai quando o elemento da camada superior é passado 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 popover 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. Ele se aplica a elementos de geometria SVG que oferecem suporte a pathLength (incluindo <path>, <circle>, <rect>, <line>, <polyline>, <polygon> e <ellipse>).
Expor pathLength como uma propriedade CSS permite que os autores a especifiquem em
folhas de estilo, estilos inline e animações, permitindo que ela participe da cascata, especificidade, transições e animações normais
do CSS. A propriedade afeta todos os cálculos que dependem do comprimento total do caminho, incluindo a renderização de traços e a posição do texto ao longo de um <textPath>.
As declarações de CSS substituem o atributo de apresentação seguindo as regras de precedência padrão do CSS. O valor inicial de path-length é none, que representa a ausência de um comprimento de caminho fornecido pelo autor e é diferente de um valor numérico explícito, como 0.
O comportamento atual de atributos é preservado quando o recurso é desativado.
APIs Web
Intl.Locale.prototype.variants
Adicione Intl.Locale.prototype.variants conforme declarado na
proposta do TC39 e também aceite
"variants" no conjunto de opções no construtor Intl.Locale, como na
atualização do ID de idioma do TC39. As mudanças no ECMA402 foram mescladas
na solicitação de pull 960 e o código de teste no test262 foi
mesclado na solicitação de pull 4474
Promessas de rolagem programática
No momento, 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 status de interrupção.
Solicitação de pagamento: permitir que os gerenciadores de pagamento informem erros internos
Permite que os manipuladores de pagamento acessados com a API Payment Request retornem erros distintos para "cancelado pelo usuário" e "erro interno do app de pagamento". Isso permite que os desenvolvedores da Web criem fluxos melhores para os usuários, por exemplo, repetindo ou voltando a um fluxo diferente quando ocorre um erro interno do app, enquanto interrompem 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 "internal app error"
(OperationError) será retornado ao comerciante usando o método PaymentRequest.show().
Caso contrário, o erro "user cancel" (AbortError) será retornado.
A infraestrutura do gerenciador de pagamentos de apps nativos também é atualizada, mas está fora do escopo das APIs da Web.
Respeitar autocorrect="off" para teclado touchscreen do Windows no TSF
O atributo HTML autocorrect permite que os autores da Web controlem se a correção automática deve ser aplicada à entrada do usuário em elementos editáveis, incluindo <input>, <textarea> e hosts contenteditable. No Windows, o teclado sensível ao toque ignora esse atributo e sempre corrige automaticamente as palavras. Por exemplo, digitar "truf" seguido de um espaço em um elemento com autocorrect="off" resulta em "true " em vez de preservar "truf ". Esse recurso faz com que a integração do TSF do Chrome detecte e reverta as correções automáticas do teclado sensível ao toque quando o elemento editável em foco tem 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). 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
Request 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 indicador é exposto principalmente no objeto Request em um FetchEvent de service worker.
Desativar filtros SVG em plug-ins e iframes entre origens e restritos
Com esse lançamento, os filtros SVG não podem ser aplicados a iframes entre origens ou restritos (por exemplo, iframes em sandbox) e plug-ins incorporados (por exemplo, PDFs). Quando um frame ou plug-in é renderizado 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
Dá aos incorporadores controle sobre o foco programático do 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 popover) 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 com foco pode passar o foco de forma programática para um iframe filho, mesmo que o filho tenha a política negada. Depois que um frame tem foco, ele pode mover o foco dentro da própria subárvore.
API de entrada orientada a eventos do gamepad
Essa proposta estende a API Gamepad com um novo modelo orientado por 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 é disparado 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 no nível da 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 no nível da origem. Isso permite que os métodos sejam instalados em uma cadeia de protótipos de 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.