Em quase todas as versões do Chrome, há um número significativo de atualizações e melhorias no produto, no desempenho e nos recursos da plataforma da Web.
No Chrome 50 (data estimada da versão Beta: de 10 a 17 de março), há várias mudanças no Chrome. Essa lista está sujeita a mudanças a qualquer momento.
O AppCache foi descontinuado em contextos não seguros.
Texto longo, leia o resumo: para dificultar o uso de scripts entre sites, descontinuamos o AppCache em origens não seguras. Esperamos que, no Chrome 52, ele só funcione em origens que servem conteúdo por HTTPS.
Intenção de remover | Rastreador Chromestatus | Bug do Chromium
O AppCache é um recurso que permite acesso off-line e persistente a uma origem, o que é uma escala de privilégios avançada para um ataque de scripting em vários sites. Como parte de um esforço maior para remover recursos poderosos em origens não seguras.
O Chrome está removendo esse vetor de ataque, permitindo-o apenas por HTTPS. Estamos descontinuando o suporte a HTTP no Chrome 50 e esperamos removê-lo totalmente no Chrome 52.
Document.defaultCharset foi removido
TL;DR: document.defaultCharset foi
removido para melhorar a conformidade com as especificações.
Intent de remoção | Rastreador Chromestatus | Problema do CRBug
O document.defaultCharset, descontinuado no Chrome 49, é uma propriedade somente leitura
que retorna a codificação de caracteres padrão do sistema do usuário com base nas
configurações regionais. Não é útil manter esse valor devido à maneira como os navegadores usam as informações de codificação de caracteres na resposta HTTP ou na metatag incorporada na página.
Em vez disso, use document.characterSet para receber o primeiro valor especificado no
cabeçalho HTTP. Se ele não estiver presente, você vai receber o valor especificado no
atributo charset do elemento <meta> (por exemplo, <meta
charset="utf-8">). Por fim, se nenhum deles estiver disponível, o
document.characterSet será a configuração do sistema do usuário.
Leia mais sobre o raciocínio para não especificar isso neste problema do GitHub.
Atributo de subrecurso removido do elemento de link
Resumo: removemos o suporte para o valor subresource do atributo rel de
HTMLLinkElement.
Intenção de remover | Rastreador Chromestatus | Bug do Chromium
A intenção do atributo subresource em <link> era pré-carregar um
recurso durante o tempo de inatividade de um navegador. Depois que um navegador faz o download de uma página, ele
pode pré-transferir recursos, como outras páginas, para que, quando solicitadas
pelos usuários, elas sejam simplesmente recuperadas do cache do navegador.
O atributo subresource teve vários problemas. Primeiro, ele nunca
funcionou como esperado. Os recursos referenciados foram transferidos por download com baixa prioridade. O
atributo nunca foi implementado em nenhum navegador além do Chrome. A implementação do Chrome tinha um bug que fazia com que os recursos fossem baixados duas vezes.
Os desenvolvedores que querem melhorar a experiência do usuário com o pré-carregamento de conteúdo
têm várias opções, sendo que a mais personalizável é criar um worker
de serviço para aproveitar o pré-cache e a API Caches. Outras soluções
incluem outros valores para o atributo rel,
incluindo preconnect, prefetch, preload, prerender. Algumas dessas
opções são experimentais e podem não ter suporte amplo.
Remover substituto não seguro da versão do TLS
Resumo: removemos um mecanismo para forçar os servidores a retornar dados usando versões de TLS menos ou não seguras.
Intent to remove | Chromestatus Tracker | Chromium Bug
O Transport Layer Security (TLS) oferece suporte a um mecanismo para negociar versões, permitindo a introdução de novas versões do TLS sem quebra de compatibilidade. Alguns servidores implementaram isso de modo que os navegadores exigiam o uso de endpoints não seguros como substituto. Por isso, os invasores poderiam forçar qualquer site, não apenas aqueles que estão configurados incorretamente, a negociar versões mais fracas de TLS.
Os sites afetados não vão conseguir se conectar com ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION. Os administradores precisam verificar se o software servidor está atualizado. Se o problema ainda não tiver sido resolvido, entre em contato com o fornecedor do software do servidor para saber se há uma correção disponível.
Remover KeyboardEvent.prototype.keyLocation
Resumo: remova um alias desnecessário para o atributo Keyboard.prototype.location.
Intent to remove | Chromestatus Tracker | Chromium Bug
Esse atributo é simplesmente um alias do atributo Keyboard.prototype.location, que permite a desambiguação entre teclas localizadas em vários
lugares em um teclado. Por exemplo, ambos os atributos permitem que os desenvolvedores
distinguam entre as duas teclas Enter em um teclado estendido.
Gerenciadores de erro e sucesso necessários nos métodos RTCPeerConnection
Resumo: os métodos WebRTC
RTCPeerConnection createOffer()
e createAnswer()
agora exigem um manipulador de erros e um manipulador de sucesso. Antes, era
possível chamar esses métodos com apenas um manipulador de sucesso. Esse uso foi
descontinuado.
Intent to remove | Chromestatus Tracker | Chromium Bug
No Chrome 49, adicionamos um aviso se você chamar
setLocalDescription()
ou setRemoteDescription()
sem fornecer um gerenciador de erros. O argumento do gerenciador de erros é obrigatório no Chrome 50.
Isso faz parte da liberação do caminho para a introdução de promessas nesses métodos, conforme exigido pela especificação WebRTC.
Confira um exemplo da demonstração de RTCPeerConnection do WebRTC (main.js, linha 126):
function onCreateOfferSuccess(desc) {
pc1.setLocalDescription(desc, function() {
onSetLocalSuccess(pc1);
}, onSetSessionDescriptionError);
pc2.setRemoteDescription(desc, function() {
onSetRemoteSuccess(pc2);
}, onSetSessionDescriptionError);
pc2.createAnswer(onCreateAnswerSuccess, onCreateSessionDescriptionError);
}
Tanto setLocalDescription() quanto setRemoteDescription() têm um
gerenciador de erros. Os navegadores mais antigos que esperam apenas um gerenciador de sucesso simplesmente
ignoram o argumento do gerenciador de erros, se ele estiver presente. Chamar esse código em um navegador
mais antigo não causa uma exceção.
Em geral, para aplicativos WebRTC de produção, recomendamos o uso de
adapter.js, um paliativo mantido pelo
projeto WebRTC, para isolar os apps de mudanças de especificação e diferenças de prefixo.
O XMLHttpRequestProgressEvent não é mais compatível
Resumo: a interface XMLHttpRequestProgressEvent será removida, junto
com os atributos position e totalSize.
Intent to remove | Chromestatus Tracker | Chromium Bug
Esse evento existia para oferecer suporte às propriedades de compatibilidade do Gecko position e
totalSize. O suporte aos três foi descontinuado no Mozilla 22, e a
funcionalidade foi substituída por
ProgressEvent há muito tempo.
var progressBar = document.getElementById("p"),
client = new XMLHttpRequest()
client.open("GET", "magical-unicorns")
client.onprogress = function(pe) {
if(pe.lengthComputable) {
progressBar.max = pe.total
progressBar.value = pe.loaded
}
}
Remover extensões de mídia criptografada com prefixo
Texto longo, leia o resumo: as extensões de mídia criptografadas com prefixo foram removidas em favor de uma substituição sem prefixo baseada em especificações.
Intenção de remover | Rastreador Chromestatus | Bug do Chromium
No Chrome 42, enviamos uma versão baseada em especificação e não prefixada de extensões de mídia criptografadas. Essa API é usada para descobrir,
selecionar e interagir com sistemas de gerenciamento de direitos digitais para uso com
HTMLMediaElement.
Isso foi há quase um ano. Como a versão não prefixada tem mais recursos do que a versão prefixada, é hora de remover a versão prefixada da API.
Remoção do suporte às propriedades SVGElement.offset
Resumo: as propriedades de deslocamento para SVGElement foram descartadas em favor das propriedades
mais amplamente compatíveis em HTMLElement.
Intent to remove | Chromestatus Tracker | Chromium Bug
As propriedades de deslocamento têm suporte de HTMLElement e
SVGElement há muito tempo. No entanto, o Gecko e o Edge só oferecem suporte a elas no HTMLElement. Para
melhorar a consistência entre os navegadores, essas propriedades foram descontinuadas no Chrome
48 e serão removidas.
Embora as propriedades equivalentes façam parte de HTMLElement, os desenvolvedores que buscam
uma alternativa também podem usar
getBoundingClientRect().