Não permitir XMLHTTPRequest() síncrono na dispensa de página
Agora, o Chrome não permite chamadas síncronas para XMLHTTPRequest() durante a dispensa
de página quando o usuário sai ou fecha a página.
Isso se aplica a beforeunload, unload, pagehide e visibilitychange.
Para garantir que os dados sejam enviados ao servidor quando uma página é descarregada, recomendamos sendBeacon() ou Fetch keep-alive. Por enquanto, usuários corporativos podem usar a
sinalização de política AllowSyncXHRInPageDismissal e os desenvolvedores podem usar a sinalização
de teste de origem allow-sync-xhr-in-page-dismissal para permitir solicitações XHR síncronas
durante o descarregamento de páginas. Essa é uma medida de "desativação" temporária e esperamos
remover essa sinalização no Chrome 88.
Para saber mais sobre isso e as alternativas, consulte Não permitir XMLHTTPRequest() síncrono durante a dispensa de páginas.
Intenção de remoção | Status da plataforma do Chrome | Bug do Chromium
Suporte a FTP descontinuado
A implementação atual de FTP no Chrome não é compatível com conexões criptografadas (FTPS, na sigla em inglês) nem proxies. O uso de FTP no navegador é tão baixo que não é mais viável investir na melhoria do cliente FTP atual. Além disso, clientes FTP mais potentes estão disponíveis em todas as plataformas afetadas.
O Chrome 72 removeu o suporte à busca de sub-recursos de documentos por FTP e à renderização de recursos de FTP de nível superior. A navegação atual dos URLs do FTP mostra uma listagem de diretórios ou um download, dependendo do tipo de recurso. Um bug no Google Chrome 74 e versões posteriores resultou na queda da compatibilidade com o acesso a URLs FTP em proxies HTTP. O suporte a proxy para FTP foi totalmente removido no Google Chrome 76.
Os recursos restantes da implementação de FTP do Google Chrome só podem exibir uma listagem de diretórios ou fazer o download de um recurso por conexões não criptografadas.
O cronograma de descontinuação é temporariamente definido da seguinte maneira:
Chrome 80 (estável em fevereiro de 2020)
O FTP está desativado por padrão para clientes não empresariais, mas pode ser ativado
usando as sinalizações de linha de comando --enable-ftp ou
--enable-features=FtpProtocol. Como alternativa, ela pode ser ativada usando a opção #enable-ftp
em chrome://flags.
Chrome 81 (estável em março de 2020)
O FTP está desativado por padrão para todas as instalações do Chrome, mas pode ser ativado
usando as sinalizações de linha de comando --enable-ftp ou
--enable-features=FtpProtocol.
Chrome 82 (estável em abril de 2020)
O suporte a FTP será completamente removido.
Intenção de remoção | Status da plataforma do Chrome | Bug do Chromium
Não permitir pop-ups durante o descarregamento da página
As páginas não podem mais usar o window.open() para abrir uma nova durante o descarregamento. O bloqueador de pop-ups do Chrome já proibiu isso, mas agora é proibido estar ou não ativado.
As empresas podem usar a sinalização de política AllowPopupsDuringPageUnload para permitir
pop-ups durante o descarregamento. O Chrome espera remover essa sinalização no Chrome 82.
Intenção de remover | Rastreador de status do Chrome | Bug do Chromium
Remoção da serialização e transferência de ImageBitmap sem limpeza de origem
Agora, erros serão gerados quando um script tentar serializar ou transferir um ImageBitmap sem origem limpa. Um ImageBitmap sem limpeza de origem é aquele que contém dados de imagens de origem cruzada que não são verificados pela lógica do CORS.
Intenção de remoção | Status da plataforma do Chrome | Bug do Chromium
O processamento de protocolos agora exige um contexto seguro
Os métodos registerProtocolHandler() e unregisterProtocolHandler() agora
exigem um contexto seguro. Esses métodos são capazes de reconfigurar os estados do cliente,
de forma a permitir a transmissão de dados potencialmente sensíveis por uma
rede.
O método registerProtocolHandler() oferece a uma página da Web um mecanismo para se registrar para processar um protocolo após o consentimento do usuário. Por exemplo, um aplicativo de e-mail baseado na Web pode se registrar para processar o esquema mailto:. Com o método unregisterProtocolHandler()
correspondente, um site pode abandonar o
registro de processamento de protocolo.
Intenção de remoção | Status da plataforma do Chrome | Bug do Chromium
Web Components v0 removido
O Web Components v0 foi removido do Chrome. As APIs Web Components v1 são um padrão de plataforma da Web que foi lançado no Chrome, Safari, Firefox e, em breve, Edge. Para orientações sobre como fazer upgrade, leia Atualização dos Web Components: mais tempo para fazer upgrade para APIs v1. Os recursos abaixo foram removidos. Essa descontinuação abrange os itens listados abaixo.
Elementos personalizados
Intenção de remoção | Status da plataforma do Chrome | Bug do Chromium
Importações HTML
Intenção de remoção | Status da plataforma do Chrome | Bug do Chromium
Shadow DOM
Intenção de remoção | Status da plataforma do Chrome | Bug do Chromium
O -webkit-appearance:button foi removido de elementos arbitrários.
-webkit-appearance:button foi mudado para funcionar apenas com os botões
<button> e <input>. Se button for especificado para um elemento não compatível, ele terá a aparência padrão. Todas as outras palavras-chave -webkit-appearance já têm essa restrição.
Intenção de remoção | Status da plataforma do Chrome | Bug do Chromium
Política de descontinuação
Para manter a integridade da plataforma, às vezes removemos APIs da plataforma Web que executaram o curso. Há vários motivos para remover uma API, como os seguintes:
- Elas foram substituídas por APIs mais recentes.
- Eles são atualizados para refletir as alterações nas especificações, visando o alinhamento e a consistência com outros navegadores.
- São experimentos iniciais que nunca se concretizaram em outros navegadores e, portanto, podem aumentar o fardo do suporte para os desenvolvedores da Web.
Algumas dessas mudanças afetam um número muito pequeno de sites. Para reduzir os problemas com antecedência, avisamos os desenvolvedores com antecedência para que eles possam fazer as mudanças necessárias e manter os sites em execução.
Atualmente, o Chrome tem um processo para descontinuações e remoções de APIs, essencialmente:
- Anuncie na lista de e-mails blink-dev.
- Defina avisos e dê escalas de tempo no Console do Chrome DevTools quando o uso for detectado na página.
- Aguarde, monitore e remova o recurso conforme diminui o uso.
É possível encontrar uma lista de todos os recursos descontinuados em chromestatus.com que usam o filtro descontinuado e dos recursos removidos com o filtro removido. Também tentaremos resumir algumas das mudanças, o raciocínio e os caminhos de migração nessas postagens.