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.
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.
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.