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.
No Chrome 49 (Beta, 2 de fevereiro de 2016. data estável estimada: março de 2016), há diversas mudanças no Chrome
O uso do prefixo "css" em getComputedStyle(e).cssX foi descontinuado
Texto longo, leia o resumo: o uso do prefixo "css" em
getComputedStyle(e)
foi descontinuado porque não fazia parte da
spec formal.
getComputedStyle é uma ótima função pequena. Ela vai retornar todos os valores CSS dos estilos do elemento DOM conforme foram calculados pelo mecanismo de renderização. Por
exemplo, é possível executar getComputedStyle(_someElement_).height e
retornar 224,1 px, porque essa é a altura do elemento que está sendo
mostrada no momento.
Parece uma API bem útil. Então, o que estamos mudando?
Antes do mecanismo de renderização do Chrome mudar para o Blink, ele usava a
WebKit e permitia usar o prefixo "css" no início de uma propriedade. Por
exemplo, getComputedStyle(e).cssHeight em vez de getComputedStyle(e).height.
Ambas retornarão os mesmos dados, conforme mapeados para os mesmos valores subjacentes,
mas esse uso do prefixo "css" não é padrão e foi
descontinuado e removido.
Observação: cssFloat é uma propriedade padrão e não será afetada por essa descontinuação.
Se você acessar uma propriedade dessa maneira no Chrome 49, ela retornará undefined e você precisará corrigir seu código.
O uso de initTouchEvent foi descontinuado
Texto longo, leia o resumo: o
initTouchEvent
foi descontinuado e substituído pelo
TouchEvent
constructor para melhorar
a conformidade com as especificações e será totalmente removido no Chrome 54.
Intenção de remover Chromestatus Tracker Problema do CRBug (em inglês)
Há muito tempo, você pode criar eventos de toque sintéticos no Chrome
usando a API initTouchEvent. Eles são usados com frequência para simular eventos de toque,
seja para testar ou automatizar parte da interface no seu site. No Chrome 49, suspendemos o uso dessa API e exibirá o seguinte aviso com a intenção de removê-la completamente no Chrome 53.
Essa mudança é boa por vários motivos.
Ela também não está na especificação de eventos de toque. A implementação de initTouchEvent no Chrome não era compatível com a API initTouchEvent do Safari e era diferente do Firefox no Android. Por fim, o construtor TouchEvent
é muito mais fácil de usar.
Foi decidido que nosso objetivo seria seguir a especificação, em vez de manter uma API
que não é especificada nem compatível com a única outra implementação.
Como resultado, primeiro vamos descontinuar e remover a função initTouchEvent
e exigir que os desenvolvedores usem o construtor TouchEvent.
Essa API há uso na Web, mas sabemos que ela é usada por um número relativamente baixo de sites. Por isso, não a removemos tão rapidamente quanto fazemos normalmente. Acreditamos que parte do uso não está funcionando porque sites não processam a versão da assinatura do Chrome.
Como as implementações do iOS e do Android/Chrome da API initTouchEvent eram muito diferentes, muitas vezes você teria algum código ao longo das linhas de (geralmente esquecendo o Firefox).
var event = document.createEvent('TouchEvent');
if(ua === 'Android') {
event.initTouchEvent(touchItem, touchItem, touchItem, "touchstart", window,
300, 300, 200, 200, false, false, false, false);
} else {
event.initTouchEvent("touchstart", false, false, window, 0, 300, 300, 200,
200, false, false, false, false, touches, targetTouches, changedTouches, 0, 0);
}
document.body.dispatchEvent(touchEvent);
Em primeiro lugar, isso é ruim porque procura por "Android" no user agent, e o Chrome no Android vai corresponder e atingir essa descontinuação. Ela ainda não pode ser removida, mas haverá outros navegadores WebKit e mais antigos baseados no Blink no Android por um tempo e você ainda vai precisar oferecer suporte à API mais antiga.
Para processar corretamente TouchEvents na Web, altere seu código para
oferecer suporte ao Firefox, IE Edge e Chrome. Para isso, verifique a existência de TouchEvent
no objeto window e, se ele tem um "comprimento" positivo (indicando que é um
construtor que recebe um argumento), use isso.
if('TouchEvent' in window && TouchEvent.length > 0) {
var touch = new Touch({
identifier: 42,
target: document.body,
clientX: 200,
clientY: 200,
screenX: 300,
screenY: 300,
pageX: 200,
pageY: 200,
radiusX: 5,
radiusY: 5
});
event = new TouchEvent("touchstart", {
cancelable: true,
bubbles: true,
touches: [touch],
targetTouches: [touch],
changedTouches: [touch]
});
}
else {
event = document.createEvent('TouchEvent');
if(ua === 'Android') {
event.initTouchEvent(touchItem, touchItem, touchItem, "touchstart", window,
300, 300, 200, 200, false, false, false, false);
} else {
event.initTouchEvent("touchstart", false, false, window, 0, 300, 300, 200,
200, false, false, false, false, touches, targetTouches,
changedTouches, 0, 0);
}
}
document.body.dispatchEvent(touchEvent);
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.
No Chrome 49, também adicionamos um aviso se você chamar
setLocalDescription()
ou setRemoteDescription()
sem fornecer um gerenciador de erros. Esperamos tornar o argumento do gerenciador de erros
obrigatório para esses métodos no 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() sempre tiveram um parâmetro de gerenciador de erros. Portanto, simplesmente especificar esse parâmetro é uma alteração segura.
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 uso de Document.defaultCharset foi descontinuado
Texto longo, leia o resumo: Document.defaultCharset foi descontinuado para melhorar a conformidade com as especificações.
Intenção de remover Chromestatus Tracker Problema do CRBug (em inglês)
O Document.defaultCharset é 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 à página.
Ao usar document.characterSet, você 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 vai ser a
configuração do sistema do usuário.
O Gecko não é compatível com essa propriedade e ela não tem especificações claras. Por isso, essa propriedade será descontinuada do Blink no Chrome 49 (Beta em janeiro de 2016). O seguinte aviso aparecerá no seu console até a remoção da propriedade no Chrome 50:
Mais discussão sobre o raciocínio para não especificar isso pode ser lida no GitHub https://github.com/whatwg/dom/issues/58 (link em inglês)
getStorageUpdates() foi removido
Texto longo, leia o resumo: Navigator.getStorageUpdates() foi removido porque não faz mais parte da
especificação do navegador.
Intenção de remover Chromestatus Tracker Problema do CRBug (em inglês)
Se isso afetar alguém, vou comer meu chapéu. O getStorageUpdates() quase nunca
foi usado na Web.
Citando a versão muito antiga da especificação HTML5:
Parece legal, não é? A especificação também usa a palavra "whence" (que, por acaso, é a única instância de quando na especificação). No nível da especificação,
havia um StorageMutex que controlava o acesso ao armazenamento de bloqueio, como
localStorage e cookies, e essa API ajudaria a liberar esse mutex para que outros
scripts não fossem bloqueados por esse StorageMutex. No entanto, ele nunca
foi implementado e não tem suporte no IE ou no Gecko, e a implementação do WebKit (e, portanto, do Blink)
é um ambiente autônomo.
Ele foi removido das especificações por um tempo e foi removido completamente do Blink. Há muito tempo, ele não funciona mais e não faz nada, mesmo que seja chamado.
Se você tiver um código que chamou navigator.getStorageUpdates(), será necessário verificar a presença da função antes de chamá-la.
O uso de Object.observe() foi descontinuado.
Texto longo, leia o resumo: Object.observe() foi descontinuado porque não está mais na faixa de padronização e será removido em uma versão futura.
Intenção de remover Chromestatus Tracker Problema do CRBug (em inglês)
Em novembro de 2015, foi anunciado que o Object.Observe seria removido do TC39. Ele foi
descontinuado no Chrome 49. Você verá o seguinte aviso no console
se tentar usá-lo:
Muitos desenvolvedores gostaram dessa API. Se você está fazendo testes com ela e agora está buscando um caminho de transição, use um polyfill, como MaxArt2501/object-observe, ou uma biblioteca de wrapper, como polymer/observe-js (links em inglês).