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.
Há várias mudanças no Chrome 50 (data estimada para a versão Beta: 10 a 17 de março). Essa lista está sujeita a alterações a qualquer momento.
AppCache descontinuado em contextos não seguros
Texto longo, leia o resumo: para dificultar o scripting em vários sites, estamos descontinuando o AppCache em origens não seguras. Esperamos que, no Chrome 52, ela funcione apenas em origens que exibem conteúdo por HTTPS.
Intenção de remover | Rastreador de status do Chrome | Bug do Chromium
O AppCache é um recurso que permite acesso off-line e permanente a uma origem, que é um escalonamento de privilégios poderoso para um ataque de scripting em vários locais. Como parte de um esforço maior para remover recursos avançados em origens não seguras.
O Chrome vai remover 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.
Texto longo, leia o resumo: document.defaultCharset foi removido para melhorar a conformidade com as especificações.
Intenção de remoção | Rastreador de status do Chrome | 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,
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 (em inglês).
Atributo de recurso secundário removido do elemento do link.
Texto longo, leia o resumo: remove o suporte para o valor subresource do atributo rel de
HTMLLinkElement.
Intenção de remover | Rastreador de status do Chrome | Bug do Chromium
A intenção do atributo subresource no <link> era fazer a pré-busca de um
recurso durante o tempo de inatividade de um navegador. Depois que um navegador faz o download de uma página, ele
pode fazer pré-download de recursos, como outras páginas, para que, quando forem
solicitados pelos usuários, eles possam ser simplesmente recuperados do cache do navegador.
O atributo subresource apresentava vários problemas. Primeiro, nunca
funcionou como pretendido. O download dos recursos referenciados foi feito com baixa prioridade. O
atributo nunca foi implementado em nenhum outro navegador além do Chrome. A implementação
do Chrome tinha um bug que fazia o download dos recursos 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. A mais personalizável é criar um service
worker para aproveitar o pré-armazenamento em cache e a API Caches. Outras soluções
incluem outros valores para o atributo rel, incluindo preconnect, prefetch, preload e prerender. Algumas opções são experimentais e podem não ter ampla compatibilidade.
Remover o substituto inseguro da versão do TLS
Texto longo, leia o resumo: remoção de um mecanismo para forçar os servidores a retornar dados usando versões menos ou não seguras do TLS.
Intenção de remover | Rastreador de status do Chrome | Bug do Chromium
O Transport Layer Security (TLS) é compatível com um mecanismo de negociação de versões, permitindo a introdução de novas versões do TLS sem interromper a compatibilidade. Em alguns servidores, isso foi necessário para que os navegadores usassem endpoints não seguros como substitutos. Por isso, os invasores podem forçar qualquer site, não apenas aqueles configurados incorretamente, a negociar versões mais fracas do TLS.
Os sites afetados não se conectarão ao ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION. Os administradores
precisam verificar se o software servidor está atualizado. Se ainda não for resolvido, entre em contato com o fornecedor do software
servidor para ver se há uma correção disponível.
KeyboardEvent.prototype.keyLocation foi removido.
TL;DR: remova um alias desnecessário para o atributo
Keyboard.prototype.location.
Intenção de remover | Rastreador de status do Chrome | Bug do Chromium
Esse atributo é simplesmente um alias para o 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
distinguem entre as duas teclas Enter em um teclado estendido.
Manipuladores de erros e sucessos necessários nos métodos RTCPeerConnection
Texto longo, leia o resumo: os métodos RTCPeerConnection createOffer() e createAnswer() (WebRTC) agora exigem um gerenciador de erros e de sucesso. Anteriormente, era possível chamar esses métodos apenas com um gerenciador de sucesso. Esse uso foi
descontinuado.
Intenção de remover | Rastreador de status do Chrome | Bug do Chromium
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 a partir do Chrome 50.
Isso faz parte da liberação de promessas nesses métodos, conforme exigido pela especificação WebRTC.
Confira um exemplo da demonstração do RTCPeerConnection (main.js, linha 126) do WebRTC:
function onCreateOfferSuccess(desc) {
pc1.setLocalDescription(desc, function() {
onSetLocalSuccess(pc1);
}, onSetSessionDescriptionError);
pc2.setRemoteDescription(desc, function() {
onSetRemoteSuccess(pc2);
}, onSetSessionDescriptionError);
pc2.createAnswer(onCreateAnswerSuccess, onCreateSessionDescriptionError);
}
Observe que setLocalDescription() e setRemoteDescription() têm um
gerenciador de erros. Navegadores mais antigos que esperam apenas um gerenciador de sucesso simplesmente ignorarão o argumento do gerenciador de erros, se ele estiver presente. Chamar esse código em um navegador mais antigo não causará uma exceção.
Em geral, para aplicativos WebRTC de produção, recomendamos usar
adapter.js, um paliativo, mantido pelo
projeto WebRTC, para isolar apps de mudanças nas especificações e diferenças de prefixo.
O XMLHttpRequestProgressEvent não é mais compatível
Texto longo, leia o resumo: a interface XMLHttpRequestProgressEvent será removida, junto
com os atributos position e totalSize.
Intenção de remover | Rastreador de status do Chrome | Bug do Chromium
Este evento existia para oferecer suporte às propriedades de compatibilidade position e
totalSize do Gecko. O suporte aos três foi descartado 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
}
}
Remoção de Encrypted Media Extensions prefixadas
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 de status do Chrome | Bug do Chromium
No Chrome 42, enviamos uma versão sem prefixo
e baseada em especificações 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. E, 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 para propriedades SVGElement.offset.
Texto longo, leia o resumo: as propriedades de deslocamento do SVGElement foram descartadas em favor das propriedades com suporte mais amplo em HTMLElement.
Intenção de remover | Rastreador de status do Chrome | Bug do Chromium
Há muito tempo, as propriedades de deslocamento são compatíveis com HTMLElement e
SVGElement. No entanto, Gecko e Edge só são compatíveis com HTMLElement. Para
melhorar a consistência entre os navegadores, essas propriedades foram descontinuadas no Chrome
48 e serão removidas.
Embora propriedades equivalentes façam parte do HTMLElement, os desenvolvedores que procuram
uma alternativa também podem usar
getBoundingClientRect()