In quasi tutte le versioni di Chrome vengono apportati un numero significativo di aggiornamenti e miglioramenti al prodotto, alle sue prestazioni e alle funzionalità della piattaforma web.
In Chrome 50 (data stimata della versione beta: 10-17 marzo) sono state apportate diverse modifiche. Questo elenco è soggetto a modifiche in qualsiasi momento.
AppCache deprecata in contesti non sicuri
TL;DR: per ostacolare lo scripting cross-site, stiamo ritirando AppCache per le origini non sicure. Prevediamo che in Chrome 52 funzionerà solo sulle origini che pubblicano contenuti tramite HTTPS.
Intento di rimozione | Tracker di Chromestatus | Bug di Chromium
AppCache è una funzionalità che consente l'accesso offline e persistente a un'origine, che è un'efficace escalation dei privilegi per un attacco cross-site scripting. Come parte di un impegno più ampio per rimuovere funzionalità efficaci da origini non sicure.
Chrome sta rimuovendo questo vettore di attacco consentendo il protocollo solo su HTTPS. Abbiamo ritirato il supporto HTTP in Chrome 50 e prevediamo di rimuoverlo del tutto in Chrome 52.
Document.defaultCharset rimosso
TL;DR: document.defaultCharset è stato
rimosso per migliorare la conformità alle specifiche.
Intento di rimozione | Tracker dello stato di Chrome | Problema CRBug
document.defaultCharset, deprecato in Chrome 49, è una proprietà di sola lettura
che restituisce la codifica dei caratteri predefinita del sistema dell'utente in base alle sue
impostazioni regionali. Non è stato ritenuto utile mantenere questo valore
a causa del modo in cui i browser utilizzano le informazioni sulla codifica dei caratteri nella
risposta HTTP o nel meta tag incorporato nella pagina.
Utilizza invece document.characterSet per ottenere il primo valore specificato nell'intestazione HTTP. Se non è presente, otterrai il valore specificato nell'attributo charset dell'elemento <meta> (ad esempio, <meta
charset="utf-8">). Infine, se nessuno di questi è disponibile, document.characterSet sarà l'impostazione di sistema dell'utente.
Puoi trovare ulteriori informazioni sul ragionamento alla base della scelta di non specificare questo aspetto in questo problema di GitHub
Attributo Subresource rimosso dall'elemento link
TL;DR: rimuovi il supporto del valore subresource per l'attributo rel di
HTMLLinkElement.
Intento di rimozione | Tracker dello stato di Chrome | Bug di Chromium
Lo scopo dell'attributo subresource su <link> era di precaricare una risorsa durante il tempo di inattività di un browser. Dopo aver scaricato una pagina, un browser potrebbe pre-scaricare risorse come altre pagine in modo da poterle recuperare semplicemente dalla cache del browser quando le richiedevano dagli utenti.
L'attributo subresource ha riscontrato diversi problemi. Innanzitutto, non ha mai
funzionato come previsto. Le risorse di riferimento sono state scaricate con priorità bassa. L'attributo non è mai stato implementato su nessun browser diverso da Chrome. L'implementazione di Chrome aveva un bug che causava il download delle risorse due volte.
Gli sviluppatori che vogliono migliorare l'esperienza utente tramite il precaricamento dei contenuti hanno a disposizione diverse opzioni, la più personalizzabile delle quali è creare un servizio worker per sfruttare la memorizzazione nella cache e l'API Caches. Altre soluzioni includono altri valori per l'attributo rel, tra cui preconnect, prefetch, preload, prerender. Alcune di queste opzioni sono sperimentali e potrebbero non essere supportate a livello generale.
Rimuovere il fallback alla versione TLS non sicura
TL;DR: rimuovi un meccanismo per forzare i server a restituire i dati utilizzando versioni meno o non sicure di TLS.
Intento di rimozione | Tracker di Chromestatus | Bug di Chromium
TLS (Transport Layer Security) supporta un meccanismo per la negoziazione delle versioni, consentendo l'introduzione di nuove versioni TLS senza interrompere la compatibilità. Alcuni server l'hanno implementata in modo tale che i browser dovevano usare endpoint non sicuri come fallback. Per questo motivo, gli utenti malintenzionati potrebbero costringere qualsiasi sito web, non solo quelli configurati in modo errato, a negoziare versioni meno sicure di TLS.
I siti interessati non riusciranno a connettersi a ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION. Gli amministratori devono assicurarsi che il software del server sia aggiornato. Se il problema persiste, contatta il fornitore
del software server per vedere se è disponibile una soluzione.
Rimuovi KeyboardEvent.prototype.keyLocation
TL;DR: rimuovi un alias non necessario per
l'attributo Keyboard.prototype.location.
Intento di rimozione | Tracker di Chromestatus | Bug di Chromium
Questo attributo è semplicemente un alias dell'attributo Keyboard.prototype.location, che consente di distinguere i tasti che si trovano in più punti su una tastiera. Ad esempio, entrambi gli attributi consentono agli sviluppatori di distinguere tra i due tasti Enter su una tastiera estesa.
Gestori di errori e di successo richiesti nei metodi RTCPeerConnection
TL;DR: i metodi createOffer() e createAnswer() di WebRTC
RTCPeerConnection ora richiedono un gestore degli errori e un gestore del successo. In precedenza, era possibile chiamare questi metodi solo con un gestore di successo. Questo utilizzo è
deprecato.
Intento di rimozione | Tracker di Chromestatus | Bug di Chromium
In Chrome 49 abbiamo aggiunto un avviso se chiami
setLocalDescription()
o setRemoteDescription()
senza fornire un gestore degli errori. L'argomento gestore degli errori è obbligatorio a partire da Chrome 50.
Questo fa parte del percorso per l'introduzione delle promesse in questi metodi, come richiesto dalla specifica WebRTC.
Ecco un esempio della demo RTCPeerConnection WebRTC (main.js, riga 126):
function onCreateOfferSuccess(desc) {
pc1.setLocalDescription(desc, function() {
onSetLocalSuccess(pc1);
}, onSetSessionDescriptionError);
pc2.setRemoteDescription(desc, function() {
onSetRemoteSuccess(pc2);
}, onSetSessionDescriptionError);
pc2.createAnswer(onCreateAnswerSuccess, onCreateSessionDescriptionError);
}
Tieni presente che sia setLocalDescription() che setRemoteDescription() hanno un gestore degli errori. I browser meno recenti che si aspettano solo un gestore di successo ignoreranno semplicemente l'argomento del gestore degli errori se è presente. La chiamata di questo codice in un browser meno recente non causerà un'eccezione.
In generale, per le applicazioni WebRTC di produzione consigliamo di utilizzare
adapter.js, uno shim, gestito dal
progetto WebRTC, per isolare le app dalle modifiche alle specifiche e dalle differenze di prefisso.
XMLHttpRequestProgressEvent non è più supportato
TL;DR: l'interfaccia XMLHttpRequestProgressEvent verrà rimossa, insieme agli attributi position e totalSize.
Intento di rimozione | Tracker dello stato di Chrome | Bug di Chromium
Questo evento esisteva per supportare le proprietà di compatibilità Gecko position e
totalSize. Il supporto di tutti e tre è stato interrotto in Mozilla 22 e la funzionalità è stata sostituita da 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
}
}
Rimuovi le estensioni dei contenuti multimediali criptati con prefisso
TL;DR: le estensioni multimediali con prefisso criptato sono state rimosse a favore di un remplacement senza prefisso basato su specifiche.
Intento di rimozione | Tracker di Chromestatus | Bug di Chromium
In Chrome 42, abbiamo distribuito una versione senza prefisso
basata su specifiche delle estensioni multimediali criptate. Questa API viene utilizzata per scoprire, selezionare e interagire con i sistemi di gestione dei diritti digitali da utilizzare con
HTMLMediaElement.
È successo quasi un anno fa. E poiché la versione senza prefisso ha più funzionalità rispetto alla versione con prefisso, è il momento di rimuovere la versione dell'API con prefisso.
Rimozione del supporto per le proprietà SVGElement.offset
TL;DR: le proprietà di offset per SVGElement sono state ritirate a favore delle proprietà più supportate su HTMLElement.
Intento di rimozione | Tracker di Chromestatus | Bug di Chromium
Le proprietà di offset sono supportate da tempo sia da HTMLElement sia da
SVGElement; tuttavia, Gecko ed Edge le supportano solo su HTMLElement. Per migliorare la coerenza tra i browser, queste proprietà sono state ritirate in Chrome 48 e ora vengono rimosse.
Sebbene le proprietà equivalenti siano parte di HTMLElement, gli sviluppatori che cercano un'alternativa possono anche utilizzare getBoundingClientRect().