In quasi tutte le versioni di Chrome, notiamo un numero significativo di aggiornamenti e miglioramenti al prodotto, alle sue prestazioni e anche alle funzionalità della piattaforma web. Questo articolo descrive i ritiri e le rimozioni in Chrome 60, in versione beta a partire dall'8 giugno. Questo elenco è soggetto a modifiche in qualsiasi momento.
Sicurezza
crypto.subtle ora richiede un'origine sicura
L'API Web Crypto, supportata da Chrome 37, ha sempre funzionato su origini non sicure. Grazie all'antica norma di Chrome che prevede la preferenza di origini sicure per funzionalità potenti, crypto.subtle non è visibile solo su origini sicure.
Intent di rimozione | Bug di Chromium
Rimuovi le navigazioni nei frame superiori avviate dai contenuti agli URL dei dati
A causa della loro poco dimestichezza con gli utenti non tecnici del browser, stiamo vedendo sempre più che lo schema data: viene utilizzato per lo spoofing e gli attacchi di phishing. Per evitare questo problema, abbiamo deciso di impedire alle pagine web di caricare data: URL nel frame superiore. Questo vale per i tag <a>, window.open, window.location e meccanismi simili. Lo schema data: continuerà a funzionare per le risorse caricate da una pagina.
Questa funzionalità era stata ritirata in Chrome 58 e ora è stata rimossa.
Intent di rimozione | Tracker di stato di Chrome | Bug di Chromium
Disattiva temporaneamente la funzione navigator.sendBeacon() per alcuni blob
La funzione navigator.sendBeacon() è disponibile a partire da Chrome 39.
Come implementato originariamente, l'argomento data della funzione potrebbe contenere qualsiasi blob arbitrario il cui tipo non è nella lista sicura CORS. Riteniamo che questa sia una potenziale minaccia alla sicurezza, anche se nessuno ha ancora provato a sfruttarla. Poiché NON abbiamo una soluzione immediata e ragionevole per questo problema, temporaneamente sendBeacon() non può più essere evocabile per i blob il cui tipo NON è nella lista sicura CORS.
Questa modifica è stata implementata per Chrome 60, ma da allora è stata unita a Chrome 59.
CSS
Fai in modo che il combinatore discendenti perforanti le ombre si comporti come il combinatore discendente
Il combinatore discendente perforando le ombre (>>>), parte del livello 1 del modulo di ambito CSS, doveva corrispondere ai figli di un particolare elemento predecessore anche quando apparivano all'interno di un albero delle ombre. Questo presentava alcune limitazioni.
Innanzitutto, in base alle specifiche, poteva essere utilizzato solo in chiamate JavaScript come querySelector() e non funzionava nei fogli di stile. Ancora più importante, i fornitori di browser non sono stati in grado di
funzionare oltre un livello del DOM Shadow.
Di conseguenza, il combinatore discendente è stato rimosso dalle specifiche pertinenti, tra cui Shadow DOM v1. Anziché interrompere le pagine web rimuovendo questo selettore da Chromium, abbiamo scelto di assegnare l'alias del combinatore discendente perforante alle ombre al combinatore discendente. Il comportamento originale è stato ritirato in Chrome 45. Il nuovo comportamento è implementato in Chrome 61.
Intent di rimozione | Tracker di stato di Chrome | Bug di Chromium
JavaScript
Depreca e rimuovi RTCPeerConnection.getStreamById()
Circa due anni fa, getStreamById() è stato rimosso dalla specifica WebRTC. La maggior parte degli altri browser l'ha già rimosso dalle proprie implementazioni. Anche se si ritiene che questa funzione sia poco utilizzata, si ritiene anche che esista un rischio di interoperabilità minore con i browser basati su Edge e WebKit diversi da Safari, in cui getStreamById() è ancora supportato. Gli sviluppatori che hanno bisogno di un'implementazione alternativa possono trovare codice di esempio nella sezione Intent da rimuovere di seguito.
La rimozione avviene in Chrome 62.
Intent di rimozione | Tracker di stato di Chrome | Bug di Chromium
Depreca SVGPathElement.getPathSegAtLength
Più di due anni fa, getPathSegAtLength() è stato rimosso dalle specifiche SVG.
Poiché esistono solo pochi hit per questo metodo in httparchive, questo metodo verrà ritirato in Chrome 60. La rimozione dovrebbe avvenire in Chrome 62, che verrà spedito a inizio o metà ottobre.
Intent di deprecazione | Tracker di stato di Chrome | Bug di Chromium
Sposta getContextAttributes() dietro un flag
La funzione getContextAttributes() è supportata su CanvasRenderingContext2D dal 2013. Tuttavia, la funzionalità non faceva parte di uno standard e da allora non ne è più diventata parte. Avrebbe dovuto essere implementato dietro il flag della riga di comando --enable-experimental-canvas-features, ma non è stato erroneamente. In Chrome 60 questa svista è stata corretta. Si ritiene che questa modifica sia sicura, dal momento che non ci sono dati che dimostrano che qualcuno sta utilizzando il metodo.
Rimuovi Headers.prototype.getAll()
La funzione Headers.prototype.getAll() viene rimossa in base all'ultima versione della specifica di recupero.
Intent di rimozione | Tracker di stato di Chrome | Bug di Chromium
Rimuovi indexDB.webkitGetDatabaseNames()
Abbiamo aggiunto questa funzionalità quando il database indicizzato era relativamente nuovo in Chrome e l'aggiunta di prefisso era di gran moda. L'API restituisce in modo asincrono un elenco di nomi di database esistenti in un'origine, che sembrava sufficientemente sensata.
Sfortunatamente, la progettazione è difettosa, in quanto i risultati possono essere obsoleti non appena vengono restituiti, pertanto può essere utilizzato solo per il logging, non per una logica applicativa seria. Il problema github monitora/link a precedenti discussioni sulle alternative, il che richiederebbe un approccio diverso. Anche se gli sviluppatori hanno suscitato un interesse costante, data la mancanza di progressi tra browser, gli autori delle biblioteche hanno risolto il problema.
Gli sviluppatori che hanno bisogno di questa funzionalità devono sviluppare la propria soluzione. Librerie come Dexie.js, ad esempio, utilizzano una tabella globale che a sua volta è un altro database per monitorare i nomi dei database.
Questa funzionalità era stata ritirata in Chrome 58 e ora è stata rimossa.
Intent di rimozione | Tracker di stato di Chrome | Bug di Chromium
Rimuovi WEBKIT_KEYFRAMES_RULE e WEBKIT_KEYFRAME_RULE
Le costanti WEBKIT_KEYFRAMES_RULE e WEBKIT_KEYFRAME_RULE non standard
vengono rimosse dalla
regola CSS.
Gli sviluppatori dovrebbero usare i criteri KEYFRAMES_RULE e KEYFRAME_RULE.
Intent di rimozione | Tracker di stato di Chrome | Bug di Chromium
Interfaccia utente
Richiedi gesto dell'utente per le finestre di dialogo prima dell'unload
A partire da Chrome 60, la finestra di dialogo beforeunload verrà visualizzata solo se il frame
che tentava di visualizzare ha ricevuto un gesto dell'utente o un'interazione dell'utente (oppure se
qualsiasi frame incorporato ha ricevuto questo gesto). Per essere chiari, questa non è una
modifica all'invio dell'evento beforeunload. È solo una modifica alla visualizzazione
della finestra di dialogo.
La finestra di dialogo beforeunload è una finestra di dialogo modale dell'app. Di conseguenza, è intrinsecamente ostile per l'utente, il che significa che risponde alla navigazione di un utente mettendo in discussione la sua decisione. Questa funzionalità è utile per scopi positivi. Ad esempio, viene spesso utilizzato
per avvisare gli utenti quando perdono dati.
La possibilità di una pagina di fornire testo per la finestra di dialogo beforeunload è stata rimossa tempo fa, ma le finestre di dialogo beforeunload rimangono un vettore di comportamento illecito. In particolare, le finestre di dialogo beforeunload sono parte integrante dei siti web fraudolenti in cui l'audio a riproduzione automatica e il testo minaccioso forniscono un contesto in cui il messaggio "Sei sicuro di voler lasciare questa pagina" diventa preoccupante.
Vogliamo infilare l'ago della bilancia e consentiamo solo usi corretti della finestra di dialogo beforeunload. I buoni utilizzi della finestra di dialogo sono quelli in cui l'utente ha uno stato che potrebbe essere perso. Se l'utente non ha mai interagito con la pagina, non può avere alcuno stato che potrebbe andare perso e, in questo caso, non rischiamo di perdere i dati dell'utente eliminando la finestra di dialogo.