Chrome 134 Beta

Rachel Andrew

Publicado em: 5 de fevereiro de 2025

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 134 está na versão Beta desde 5 de fevereiro de 2025. Faça o download da versão mais recente em Google.com para computador ou na Google Play Store para Android.

CSS

Nesta versão, adicionamos cinco novos recursos de CSS e interface.

Propriedade dynamic-range-limit do CSS

Permite que uma página limite o brilho máximo do conteúdo HDR.

Elemento <select> personalizável

Adicione a capacidade de personalizar elementos HTML <select> ativando o novo comportamento com o valor base-select de appearance. Depois de ativar, você pode adicionar conteúdo avançado, incluindo imagens, e também estilizar as opções.

Dispensar caixa de diálogo com toque

Um dos recursos interessantes da API Popover é o comportamento de dispensa leve. Esse recurso oferece a mesma capacidade ao <dialog>. Um novo atributo closedby controla o comportamento:

• <dialog closedby=none>: não há fechamento de caixas de diálogo acionado pelo usuário.
• <dialog closedby=closerequest>: pressionar ESC (ou outro gatilho de fechamento) fecha a caixa de diálogo.
• <dialog closedby=any>: clicar fora da caixa de diálogo ou pressionar ESC fecha a caixa de diálogo. O mesmo comportamento de popover=auto.

Herança de destaque do CSS

Com a herança de destaque do CSS, as pseudoclasses de destaque do CSS, como ::selection e ::highlight, herdam as propriedades pela cadeia de pseudodestaque, em vez da cadeia de elementos. O resultado é um modelo mais intuitivo para herança de propriedades em destaques.

Para saber mais, leia a postagem do blog Mudanças na herança para estilização de seleção de CSS (em inglês), escrita por Stephen Chenney da Igalia.

Pseudoclasse :has-slotted

A pseudoclasse :has-slotted representa um elemento de slot com conteúdo inserido, como um nó de texto ou um elemento. Isso pode ser usado para estilizar elementos com base em se eles estão usando conteúdo de substituição de slot ou não.

APIs Web

Recurso de relatórios de atribuição: remover o limite de relatórios agregáveis quando o ID de contexto do acionador não é nulo

Essa mudança é baseada no feedback do caller da API e na necessidade de medir um número maior de eventos de conversão para determinados fluxos de usuários.

No momento, a API tem um limite que permite gerar até 20 relatórios agregáveis por registro de origem, o que é restritivo para casos de uso em que um usuário pode ter uma jornada mais longa. Essa mudança remove o limite de relatórios agregáveis quando um ID de contexto de acionamento é fornecido como parte do registro. A remoção desse limite é restrita apenas a quando o ID de contexto do gatilho é especificado. Isso porque, quando ele é especificado, a API aplica uma taxa maior de relatórios nulos, o que ajuda a proteger contra vazamentos de informações entre sites por contagens de relatórios.

Além disso, os relatórios agregáveis ainda estarão sujeitos a outros limites que restringem a quantidade total de informações que podem ser medidas, como o orçamento de contribuição L1 (65.536) por origem e o limite de taxa de atribuição.

Particionamento de URL de blobs: busca/navegação

Como continuação do particionamento de armazenamento, implementa o particionamento do acesso ao URL do blob por chave de armazenamento (site de nível superior, origem do frame e o booleano has-cross-site-ancestor), com exceção das navegações de nível superior que vão permanecer particionadas apenas pela origem do frame. Esse comportamento é semelhante ao que é implementado atualmente pelo Firefox e pelo Safari, e alinha o uso do URL do blob com o esquema de particionamento usado por outras APIs de armazenamento como parte do particionamento de armazenamento. Além disso, o Chrome vai aplicar o noopener em navegações de alto nível iniciadas pelo renderizador para URLs blob em que o site correspondente é de um domínio diferente em relação ao site de nível superior que realiza a navegação. Isso alinha o Chrome a um comportamento semelhante no Safari, e as especificações relevantes foram atualizadas para refletir essas mudanças.

Essa mudança pode ser revertida temporariamente definindo a política PartitionedBlobURLUsage. A política será descontinuada quando as outras políticas corporativas relacionadas ao particionamento de armazenamento forem descontinuadas.

Document-Policy: expect-no-linked-resources

O ponto de configuração expect-no-linked-resources na política de documentos permite que uma dica de documento para o user agent otimize melhor a sequência de carregamento, como não usar o comportamento de análise especulativa padrão (também conhecido como scanner de pré-carregamento).

Os user agents implementaram a análise especulativa de HTML para buscar especulativamente recursos presentes na marcação HTML e acelerar o carregamento da página. Para a grande maioria das páginas na Web que têm recursos declarados na marcação HTML, a otimização é benéfica, e o custo pago para determinar esses recursos é uma troca razoável. No entanto, os cenários a seguir podem resultar em uma troca de performance abaixo do ideal em comparação com o tempo gasto explicitamente analisando HTML para determinar os sub-recursos a serem buscados:

• Páginas que não têm recursos declarados no HTML.
• Páginas HTML grandes com carregamentos de recursos mínimos ou inexistentes que podem controlar explicitamente os recursos de pré-carregamento usando outros mecanismos disponíveis.

A expect-no-linked-resources Document-Policy sugere ao User-Agent que ele pode otimizar o tempo gasto nessa determinação de sub-recursos.

Gerenciamento explícito de recursos (assíncrono e síncrono)

Esses recursos abordam um padrão comum no desenvolvimento de software em relação ao tempo de vida e ao gerenciamento de vários recursos (por exemplo, memória e E/S). Esse padrão geralmente inclui a alocação de um recurso e a capacidade de liberar explicitamente recursos críticos.

Estender a API console.timeStamp para oferecer suporte a medições e opções de apresentação

Esse recurso estende a API console.timeStamp() de maneira compatível com versões anteriores para fornecer um método de alto desempenho para instrumentar aplicativos e mostrar dados de tempo no painel "Performance" das DevTools.

As entradas de tempo adicionadas com a API podem ter um carimbo de data/hora, uma duração e opções de apresentação personalizadas (faixa, raia e cor).

OffscreenCanvas getContextAttributes

Adiciona a interface getContextAttributes de CanvasRenderingContext2D a OffscreenCanvasRenderingContext2D.

API Private Aggregation: limites de contribuição por contexto para chamadores do Shared Storage

Permite que os chamadores da Shared Storage personalizem o número de contribuições por relatório de agregação privada.

Esse recurso permite que os chamadores do armazenamento compartilhado configurem limites de contribuição por contexto com um novo campo, maxContributions. Os chamadores definem esse campo para substituir o número padrão de contribuições por relatório. Números maiores e menores são permitidos. O Chrome aceita valores de maxContributions entre 1 e 1.000, inclusive. Valores maiores serão interpretados como 1.000.

Devido ao padding, o tamanho do payload de cada relatório será aproximadamente proporcional ao número escolhido de contribuições por relatório. Esperamos que a opção por relatórios maiores aumente o custo de operação do Serviço de agregação.

Os chamadores do Protected Audience não serão afetados por esse recurso. No entanto, estamos planejando adicionar suporte para personalizar o número de contribuições nos relatórios de público-alvo protegido em recursos futuros.

Suporte a ImageSmoothingQuality em PaintCanvas

Adição de suporte ao atributo imageSmoothingQuality no Paint Canvas. Ele permite que um desenvolvedor da Web escolha a qualidade em vez da compensação de desempenho ao dimensionar imagens. Há três opções válidas para imageSmoothingQuality: low, medium e high.

Subgrupos da WebGPU

Adiciona funcionalidade de subgrupo ao WebGPU. As operações de subgrupo realizam operações SIMT para fornecer comunicação e compartilhamento de dados eficientes entre grupos de invocações. Essas operações podem ser usadas para acelerar aplicativos, reduzindo as sobrecargas de memória causadas pela comunicação entre invocações.

Novos testes de origem

No Chrome 134, você pode ativar os seguintes novos testes de origem.

API Digital Credential

Os sites podem e recebem credenciais de apps de carteira digital para dispositivos móveis por vários mecanismos, como processadores de URL personalizados e leitura de QR code. Com esse recurso, os sites podem solicitar informações de identidade das carteiras usando o sistema IdentityCredential CredMan do Android. Ele é extensível para oferecer suporte a vários formatos de credenciais (por exemplo, ISO mDoc e W3C verifiable credential) e permite o uso de vários apps de carteira. Estamos adicionando mecanismos para reduzir o risco de abuso em grande escala no ecossistema da identidade no mundo real.

O teste de origem que começa no Chrome 134 adiciona suporte a essa API na plataforma de computador, em que o Chrome para computador se comunica com segurança com a carteira digital no smartphone Android para buscar as credenciais solicitadas.

Descontinuações e remoções

Esta versão do Chrome apresenta as suspensões de uso e remoções listadas abaixo. Acesse ChromeStatus.com para conferir listas de suspensões de uso planejadas, atuais e remoções anteriores.

Esta versão do Chrome remove um recurso.

Remover restrições de áudio não padrão do getUserMedia

O Blink é compatível com várias restrições não padrão com prefixo goog para getUserMedia desde algum tempo antes de as restrições serem padronizadas corretamente.

O uso diminuiu significativamente, ficando entre 0,000001% e 0,0009% (dependendo da restrição), e algumas delas nem têm efeito devido a mudanças na pilha de captura de áudio do Chromium. Em breve, nenhuma restrição terá efeito devido a outras mudanças.

Não esperamos que essa mudança cause uma regressão relevante. Os aplicativos que usam essas restrições vão continuar funcionando, mas receberão áudio com as configurações padrão, como se nenhuma restrição tivesse sido transmitida. É possível migrar para restrições padrão.