Publicado em 5 de fevereiro de 2025
A menos que indicado de outra forma, 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 do ChromeStatus.com. O Chrome 134 é Beta desde 5 de fevereiro de 2025. Faça o download da versão mais recente em Google.com para computadores ou na Google Play Store no 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 <select> HTML ativando o novo
comportamento com o valor base-select de appearance. Depois de ativar, você pode
adicionar conteúdo rico, incluindo imagens, e estilizar as opções.
Dispensa da luz da caixa de diálogo
Um dos recursos interessantes da API Popover é o comportamento de dispensa leve. Esse
recurso traz a mesma capacidade para <dialog>. Um novo atributo closedby
controla o comportamento:
<dialog closedby=none>: nenhuma caixa de diálogo é fechada pelo usuário.<dialog closedby=closerequest>: pressionarESC(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 que o comportamento depopover=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
destaque de pseudoelementos, 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 Inheritance changes for CSS selection styling , escrita por Stephen Chenney, da Igalia.
Pseudoclasse :has-slotted
A pseudoclasse :has-slotted representa um elemento de slot com conteúdo de slot,
como um nó ou elemento de texto. Isso pode ser usado para estilizar elementos com base
em se eles estão ou não usando o conteúdo de fallback do slot.
APIs Web
Recurso de relatórios de atribuição: o limite de relatórios agregáveis foi removido quando o ID do contexto do acionador não é nulo
Essa mudança é baseada no feedback do autor da chamada 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 agregados quando um ID de contexto do acionador é fornecido como parte do registro. A remoção desse limite é restrita apenas quando o ID do contexto do acionador é especificado. Quando isso acontece, a API aplica uma taxa maior de relatórios nulos, o que ajuda a proteger contra vazamentos de informações entre sites em contagens de relatórios.
Além disso, os relatórios agregáveis ainda são limitados por 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 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 nível superior 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 em Document-Policy permite que um
documento sugira ao agente do usuário que ele otimize melhor a sequência de carregamento, por exemplo,
não usando o comportamento de análise especulativa padrão (também conhecido como
verificador de pré-carregamento).
Os user agents implementaram a análise especulativa de HTML para buscar especulativamente recursos presentes na marcação HTML, a fim de acelerar o carregamento da página. Para a grande maioria das páginas da Web que têm recursos declarados no marcador de elementos HTML, a otimização é benéfica, e o custo pago para determinar esses recursos é uma boa troca. No entanto, os seguintes cenários podem resultar em uma troca de desempenho subótima em relação ao tempo explícito gasto na análise de HTML para determinar os subrecursos a serem buscados:
- Páginas que não têm recursos declarados no HTML.
- Páginas HTML grandes com cargas mínimas ou nenhuma carga de recursos que poderiam controlar explicitamente os recursos de pré-carregamento usando outros mecanismos de pré-carregamento disponíveis.
A política de documentos expect-no-linked-resources sugere ao agente do usuário que ele
pode otimizar o tempo gasto na determinação do subrecurso.
Gerenciamento explícito de recursos (assíncrono e síncrono)
Esses recursos abordam um padrão comum no desenvolvimento de software em relação à duração 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 recursos críticos explicitamente.
A API console.timeStamp foi ampliada para oferecer suporte a medições e opções de apresentação
Esse recurso estende a API console.timeStamp(), de forma compatível com versões
anteriores, para oferecer um método de alto desempenho para instrumentar aplicativos e
exibir dados de tempo no painel Performance nas Ferramentas do desenvolvedor.
As entradas de tempo adicionadas com a API podem ter um carimbo de data/hora personalizado, duração e opções de apresentação (faixa, swimlane e cor).
OffscreenCanvas getContextAttributes
Adiciona a interface getContextAttributes de CanvasRenderingContext2D a
OffscreenCanvasRenderingContext2D.
API Private Aggregation: limites de contribuição por contexto para autores de chamada do Shared Storage
Permite que os autores de chamadas do Shared Storage personalizem o número de contribuições por relatório de agregação privada.
Esse recurso permite que os autores de chamadas do Shared Storage configurem limites de contribuição
por contexto com um novo campo, maxContributions. Os autores da chamada 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. Valores maiores são interpretados como 1.000.
Devido ao padding, o tamanho do payload de cada relatório será aproximadamente proporcional ao número de contribuições escolhido por relatório. Esperamos que a ativação de relatórios maiores aumente o custo de operação do serviço de agregação.
Os autores de chamadas da API Protected Audience não serão afetados por esse recurso. No entanto, planejamos adicionar suporte à personalização do número de contribuições para os relatórios da API Protected Audience em recursos futuros.
Suporte a ImageSmoothingQuality no PaintCanvas
Adição de suporte ao atributo imageSmoothingQuality na tela de pintura Ele permite
que um desenvolvedor da Web escolha a troca de qualidade por desempenho ao redimensionar imagens.
Há três opções válidas para imageSmoothingQuality: low, medium e
high.
Subgrupos da WebGPU
Adiciona a funcionalidade de subgrupo à WebGPU. As operações de subgrupo executam operações de 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 a sobrecarga de memória gerada 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 carteiras para dispositivos móveis por vários
mecanismos, como processadores de URL personalizados e leitura de código QR. Esse
recurso permite que os sites solicitem informações de identidade de carteiras usando o sistema
IdentityCredential CredMan do Android. Ele é extensível para oferecer suporte a vários
formatos de credencial (por exemplo, ISO mDoc e credencial verificável do W3C) e
permite que vários apps de carteira sejam usados. Estamos adicionando mecanismos para ajudar
a reduzir o risco de abuso de identidade no ecossistema.
O teste de origem a partir do Chrome 134 adiciona suporte a essa API na plataforma de computador, em que o Chrome no computador se comunica com segurança com a carteira digital no smartphone Android para buscar as credenciais solicitadas.
Suspensões de uso e remoções
Esta versão do Chrome apresenta as descontinuações e remoções listadas abaixo. Acesse o ChromeStatus.com para conferir listas de descontinuações planejadas, descontinuações atuais e remoções anteriores.
Esta versão do Chrome remove um recurso.
Remover restrições de áudio não padrão de 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 de ~0,000001% para 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 delas vai ter efeito devido a outras mudanças futuras.
Não esperamos nenhuma regressão importante devido a essa mudança. Os apps que usam essas restrições vão continuar funcionando, mas vão receber áudio com as configurações padrão, como se nenhuma restrição tivesse sido transmitida. Eles podem migrar para restrições padrão.