Descontinuações e remoções no Chrome 60

Joe medley
Joe Medley

Em quase todas as versões do Chrome, vemos um número significativo de atualizações e melhorias no produto, no desempenho dele e também nos recursos da plataforma da Web. Neste artigo, descrevemos as descontinuações e remoções do Chrome 60, que está na versão Beta desde 8 de junho. Essa lista está sujeita a alterações a qualquer momento.

Segurança

crypto.subtle agora exige uma origem segura.

A API Web Crypto, que tem suporte desde o Chrome 37, sempre funcionou em origens não seguras. Devido à política de longa data do Chrome de priorizar origens seguras para recursos avançados, crypto.subtle não é visível apenas em origens seguras.

Intenção de remoção | Bug do Chromium

Remover navegações dos principais frames iniciadas pelo conteúdo para os URLs de dados

Como os usuários não técnicos não conhecem o navegador, o esquema data: é cada vez mais usado em ataques de spoofing e phishing. Para evitar isso, estamos bloqueando o carregamento de URLs data: de páginas da Web no frame superior. Isso se aplica a tags <a>, window.open, window.location e mecanismos semelhantes. O esquema data: ainda funciona para recursos carregados por uma página.

Este recurso foi descontinuado no Chrome 58 e removido.

Intenção de remover | Rastreador de status do Chrome | Bug do Chromium

Desativar temporariamente o Navigator.sendBeacon() para alguns blobs

A função navigator.sendBeacon() está disponível desde o Chrome 39. Conforme implementado originalmente, o argumento data da função pode conter qualquer blob arbitrário cujo tipo não esteja na lista de permissões do CORS. Acreditamos que essa é uma possível ameaça à segurança, mas ninguém ainda tentou explorá-la. Como NÃO temos uma correção imediata razoável para isso, temporariamente, sendBeacon() não pode mais ser invocável em blobs cujo tipo NÃO está na lista de permissões do CORS.

Embora essa mudança tenha sido implementada no Chrome 60, ela foi mesclada ao Chrome 59.

Bug do Chromium

CSS

Faz com que o combinador descendente descendente que diferencie as sombras se comporte como o combinador descendente

O combinador descendente descendente esporádico (>>>), parte do Módulo de escopo CSS de nível 1, estava associado aos filhos de um determinado elemento ancestral, mesmo quando eles apareciam dentro de uma árvore paralela. Isso tinha algumas limitações. Primeiro, de acordo com a especificação, ele só podia ser usado em chamadas JavaScript, como querySelector(), e não funcionava em folhas de estilo. O mais importante é que os fornecedores de navegadores não conseguiram fazer com que ele funcionasse além de um nível do Shadow DOM.

Consequentemente, o combinador descendente foi removido das especificações relevantes, incluindo o Shadow DOM v1. Em vez de quebrar páginas da Web removendo esse seletor do Chromium, optamos por atribuir um alias ao combinador descendente que esconde sombras para o combinador descendente. O comportamento original foi descontinuado no Chrome 45. O novo comportamento foi implementado no Chrome 61.

Intenção de remover | Rastreador de status do Chrome | Bug do Chromium

JavaScript

O uso e a remoção de RTCPeerConnection.getStreamById() foram descontinuados.

Há quase dois anos, o getStreamById() foi removido da especificação WebRTC. A maioria dos outros navegadores já removeu esse recurso das implementações. Embora acredite-se que essa função seja pouco usada, ela também pode apresentar alguns riscos pequenos de interoperabilidade com navegadores baseados no Edge e no WebKit, além do Safari em que getStreamById() ainda é compatível. Os desenvolvedores que precisam de uma implementação alternativa podem encontrar um exemplo de código na intent de remoção abaixo.

A remoção ocorrerá no Chrome 62.

Intenção de remover | Rastreador de status do Chrome | Bug do Chromium

O uso de SVGPathElement.getPathSegAtLength foi descontinuado.

Há mais de dois anos, o getPathSegAtLength() foi removido da especificação do SVG. Como há apenas alguns hits para esse método em httparchive, ele está sendo descontinuado no Chrome 60. A remoção está prevista para o Chrome 62, que será enviado no início ou na metade de outubro.

Intenção de descontinuação | Rastreador do Chromestatus | Bug do Chromium

Mover getContextAttributes() para trás de uma sinalização

A função getContextAttributes() tem suporte no CanvasRenderingContext2D desde 2013. No entanto, o recurso não fazia parte de nenhum padrão e não se tornou parte de um padrão desde então. Ela deveria ter sido implementada por trás da flag de linha de comando --enable-experimental-canvas-features, mas não foi por engano. No Chrome 60, esse problema foi corrigido. Acredita-se que essa mudança é segura, já que não há dados mostrando que alguém está usando o método.

Bug do Chromium

Remover Headers.prototype.getAll()

A função Headers.prototype.getAll() está sendo removida de acordo com a versão mais recente da especificação de busca.

Intenção de remover | Rastreador de status do Chrome | Bug do Chromium

Remoção de indexarDB.webkitGetDatabaseNames()

Adicionamos esse recurso quando o Indexed DB era relativamente novo no Chrome, e o prefixo era muito comum. A API retorna de maneira assíncrona uma lista de nomes de bancos de dados existentes em uma origem, que pareciam razoáveis o suficiente.

Infelizmente, o design é falho, já que os resultados podem ficar obsoletos assim que são retornados. Portanto, ele só pode ser usado para geração de registros, não para uma lógica de aplicativo séria. O problema no github (link em inglês) rastreia/vincula a uma discussão anterior sobre alternativas, o que exigiria uma abordagem diferente. Os desenvolvedores têm bastante interesse, mas devido à falta de progresso entre navegadores, o problema foi resolvido pelos autores das bibliotecas.

Os desenvolvedores que precisam dessa funcionalidade precisam desenvolver a própria solução. Bibliotecas como Dexie.js, por exemplo, usam uma tabela global, que é outro banco de dados para rastrear os nomes dos bancos de dados.

Este recurso foi descontinuado no Chrome 58 e removido.

Intenção de remover | Rastreador de status do Chrome | Bug do Chromium

Remover WEBKIT_KEYFRAMES_RULE e WEBKIT_KEYFRAME_RULE

As constantes WEBKIT_KEYFRAMES_RULE e WEBKIT_KEYFRAME_RULE não padrão foram removidas da Regra CSS. Os desenvolvedores precisam usar KEYFRAMES_RULE e KEYFRAME_RULE

Intenção de remover | Rastreador de status do Chrome | Bug do Chromium

Interface do usuário

Exigir gesto do usuário para caixas de diálogo do tipo beforeunload

A partir do Chrome 60, a caixa de diálogo beforeunload só vai aparecer se o frame que está tentando exibi-lo tiver recebido um gesto ou interação do usuário (ou se qualquer frame incorporado tiver recebido esse gesto). Para esclarecer, essa não é uma mudança no envio do evento beforeunload. É apenas uma mudança na exibição da caixa de diálogo.

A caixa de diálogo beforeunload é uma caixa de diálogo modal do app. Portanto, é inerentemente hostil ao usuário, o que significa que ele responde à navegação do usuário questionando a decisão dele. Esse recurso tem usos positivos. Por exemplo, ele costuma ser usado para avisar os usuários quando eles perderão dados pela navegação.

Embora a capacidade de uma página fornecer texto para a caixa de diálogo beforeunload tenha sido removida há algum tempo, as caixas de diálogo beforeunload continuam sendo um vetor de abuso. Especificamente, as caixas de diálogo beforeunload são um ingrediente de sites de golpes, em que o áudio de reprodução automática e o texto ameaçador fornecem um contexto em que a mensagem "Tem certeza de que você quer sair desta página?" se torna preocupante.

Queremos encadear a agulha e só permitimos bons usos da caixa de diálogo beforeunload. Bons usos da caixa de diálogo são aqueles em que o usuário tem um estado que pode ser perdido. Se o usuário nunca interagiu com a página, ele não pode ter nenhum estado que possa ser perdido. Portanto, não corremos o risco de perder dados do usuário ao suprimir a caixa de diálogo nesse caso.