Em quase todas as versões do Chrome, notamos 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: 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.
RESUMO: para impedir o scripting em vários sites, estamos descontinuando o AppCache em origens não seguras. Esperamos que, no Chrome 52, ele só funcione em origens que servem conteúdo por HTTPS.
Intent to remove | Chromestatus Tracker | Chromium Bug
O AppCache é um recurso que permite o acesso off-line e persistente a uma origem, o que é uma elevação de privilégios poderosa para um ataque de script entre 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 apenas o acesso por HTTPS. Estamos descontinuando o suporte a HTTP no Chrome 50 e planejamos removê-lo totalmente no Chrome 52.
Document.defaultCharset foi removido
TL;DR: document.defaultCharset foi
removida para melhorar a conformidade com as especificações.
Intent to Remove | Chromestatus Tracker | CRBug Issue
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 foi útil manter esse valor
porque os navegadores usam as informações de codificação de caracteres na
resposta HTTP ou na metatag incorporada à 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.
Intent to remove | Chromestatus Tracker | Chromium Bug
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 transferidos por download 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, como preconnect, prefetch, preload e prerender. Algumas dessas
opções são experimentais e podem não ter suporte amplo.
Remover o substituto inseguro 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
A camada de segurança de transporte (TLS) oferece suporte a um mecanismo para negociar versões, permitindo a introdução de novas versões do TLS sem comprometer a compatibilidade. Alguns servidores implementaram isso de forma que os navegadores precisavam usar 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
devem garantir que o software do servidor esteja 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
distingam as duas teclas Enter em um teclado estendido.
Os manipuladores de erros e sucesso são 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 abertura do caminho para a introdução de promessas nesses métodos, conforme exigido pela especificação do 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);
}
setLocalDescription() e 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 para os três foi descontinuado no Mozilla 22, e a
funcionalidade foi substituída há muito tempo pelo
ProgressEvent.
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
RESUMO: as extensões de mídia criptografadas com prefixo foram removidas em favor de uma substituição sem prefixo baseada em especificações.
Intent to remove | Chromestatus Tracker | Chromium Bug
No Chrome 42, lançamos uma versão com base na especificação
sem prefixo 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.
O suporte às propriedades SVGElement.offset foi removido.
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ó têm suporte para elas no HTMLElement. Para
melhorar a consistência entre os navegadores, essas propriedades foram descontinuadas no Chrome
48 e agora estão sendo removidas.
Embora as propriedades equivalentes façam parte de HTMLElement, os desenvolvedores que procuram
uma alternativa também podem usar
getBoundingClientRect().