Rimozioni e ritiri di API in Chrome 50

Joe Medley
Mario Bianchi

In quasi ogni versione di Chrome notiamo un numero significativo di aggiornamenti e miglioramenti al prodotto, alle sue prestazioni e anche alle funzionalità della piattaforma web.

In Chrome 50 (data beta stimata: dal 10 al 17 marzo) sono state apportate diverse modifiche a Chrome. Questo elenco è soggetto a modifiche in qualsiasi momento.

AppCache deprecata in contesti non sicuri

TL;DR: per impedire il cross-site scripting, stiamo ritirando AppCache su origini non sicure. Prevediamo che in Chrome 52 funzionerà solo su origini che pubblicano contenuti tramite HTTPS.

Intent di rimozione | Tracker di stato di Chrome | Bug di Chromium

AppCache è una funzionalità che consente l'accesso offline e permanente a un'origine, che rappresenta una potente escalation dei privilegi per un attacco cross-site scripting. Nell'ambito di un impegno più ampio volto a rimuovere funzionalità potenti su origini non sicure.

Chrome sta rimuovendo questo vettore di attacco consentendolo solo tramite HTTPS. Stiamo ritirando il supporto HTTP in Chrome 50 e prevediamo di rimuoverlo completamente in Chrome 52.

Document.defaultCharset è stato rimosso

TL;DR: document.defaultCharset è stato rimosso per migliorare la conformità delle specifiche.

Intent di rimozione | Tracker di stato di Chrome | Problema CRBug

document.defaultCharset, deprecata in Chrome 49, è una proprietà di sola lettura che restituisce la codifica dei caratteri predefinita del sistema dell'utente in base alle impostazioni regionali. È stato riscontrato che non è 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, verrà visualizzato il valore specificato nell'attributo charset dell'elemento <meta> (ad esempio, <meta charset="utf-8">). Infine, se nessuno di questi elementi è disponibile, document.characterSet corrisponderà all'impostazione di sistema dell'utente.

Puoi consultare ulteriori informazioni sul ragionamento per non specificarlo in questo problema di GitHub

TL;DR: rimuovi il supporto del valore subresource per l'attributo rel di HTMLLinkElement.

Intent di rimozione | Tracker di stato di Chrome | Bug di Chromium

Lo scopo dell'attributo subresource su<link> era il precaricamento di una risorsa durante il tempo di inattività del browser. Dopo che un browser ha scaricato una pagina, potrebbe prescaricare risorse come altre pagine in modo che, quando richieste dagli utenti, possano semplicemente essere recuperate dalla cache del browser.

L'attributo subresource ha riscontrato diversi problemi. In primo luogo, non ha mai funzionato come previsto. Le risorse di riferimento sono state scaricate con priorità bassa. L'attributo non è mai stato implementato in nessun browser diverso da Chrome. L'implementazione di Chrome aveva un bug a causa del quale le risorse venivano scaricate due volte.

Gli sviluppatori che vogliono migliorare l'esperienza utente mediante il precaricamento dei contenuti hanno varie opzioni, la più personalizzabile delle quali è creare un service worker per sfruttare la precaching e l'API Caches. Le soluzioni aggiuntive includono altri valori per l'attributo rel tra cui preconnect, prefetch, preload, prerender. Alcune di queste opzioni sono sperimentali e potrebbero non essere ampiamente supportate.

Rimuovi la versione TLS non sicura di riserva

TL;DR: rimuovi un meccanismo che obbliga i server a restituire dati utilizzando versioni meno sicure o non sicure di TLS.

Intent di rimozione | Tracker di stato di Chrome | Bug di Chromium

TLS (Transport Layer Security) supporta un meccanismo di 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 dovessero utilizzare endpoint non sicuri come fallback. Per questo motivo, i malintenzionati potrebbero forzare qualsiasi sito web, non solo quelli configurati in modo errato, a negoziare per versioni più deboli di TLS.

I siti interessati non si connetteranno a ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION. Gli amministratori devono assicurarsi che il software dei server sia aggiornato. Se il problema persiste, contatta il fornitore del software server per verificare se è disponibile una correzione.

Rimuovi KeyboardEvent.prototype.keyLocation

TL;DR: rimuovi un alias non necessario per l'attributo Keyboard.prototype.location.

Intent di rimozione | Tracker di stato di Chrome | Bug di Chromium

Questo attributo è semplicemente un alias dell'attributo Keyboard.prototype.location, che consente la disambiguazione tra i tasti che si trovano in più posizioni su una tastiera. Ad esempio, entrambi gli attributi consentono agli sviluppatori di distinguere i due tasti Enter su una tastiera estesa.

Gestori di errori e successi obbligatori nei metodi RTCPeerConnection

TL;DR: i metodi WebRTC RTCPeerConnection createOffer() e createAnswer() ora richiedono un gestore degli errori oltre a un gestore del successo. In precedenza era possibile chiamare questi metodi solo con un gestore dei successi. Questo utilizzo è obsoleto.

Intent di rimozione | Tracker di stato di Chrome | Bug di Chromium

In Chrome 49 abbiamo aggiunto un avviso se chiami setLocalDescription() o setRemoteDescription() senza fornire un gestore degli errori. L'argomento del gestore degli errori è obbligatorio a partire dalla versione 50 di Chrome.

Questo consente di aprire la strada all'introduzione di promesse per questi metodi, come richiesto dalle specifiche WebRTC.

Ecco un esempio tratto dalla demo di una connessione RTCPeerConnection su 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 dei risultati positivi ignorano semplicemente l'argomento del gestore degli errori se presente; la chiamata a questo codice in un browser meno recente non genera 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 nei prefissi.

XMLHttpRequestProgressEvent non è più supportato

TL;DR: l'interfaccia XMLHttpRequestProgressEvent verrà rimossa, insieme agli attributi position e totalSize.

Intent di rimozione | Tracker di stato di Chrome | Bug di Chromium

Questo evento esisteva per supportare le proprietà di compatibilità di Gecko position e totalSize. Il supporto per tutti e tre è stato interrotto in Mozilla 22 e la funzionalità è stata a lungo 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 Encrypted Media Extensions con prefisso

TL;DR: le estensioni multimediali criptate con prefisso sono state rimosse e sostituite da una sostituzione senza prefisso basata sulle specifiche.

Intent di rimozione | Tracker di stato di Chrome | Bug di Chromium

In Chrome 42, abbiamo spedito una versione basata sulle specifiche e senza prefisso delle estensioni multimediali criptate. Questa API viene utilizzata per scoprire, selezionare e interagire con sistemi di gestione dei diritti digitali da utilizzare con HTMLMediaElement.

Quasi un anno fa. Inoltre, poiché la versione senza prefisso ha più funzionalità rispetto alla versione con prefisso, è il momento di rimuovere la versione con prefisso dell'API.

Rimozione del supporto delle proprietà SVGElement.offset

TL;DR: le proprietà di offset per SVGElement sono state eliminate a favore delle proprietà più supportate su HTMLElement.

Intent di rimozione | Tracker di stato di Chrome | Bug di Chromium

Le proprietà di offset sono supportate da tempo sia da HTMLElement che da SVGElement; tuttavia, Gecko ed Edge le supportano solo su HTMLElement. Per migliorare la coerenza tra i browser, queste proprietà erano deprecate in Chrome 48 e ora sono in fase di rimozione.

Sebbene le proprietà equivalenti facciano parte di HTMLElement, gli sviluppatori alla ricerca di un'alternativa possono utilizzare anche getBoundingClientRect()