Bei fast jeder Chrome-Version gibt es eine große Anzahl von Updates und Verbesserungen am Produkt, an seiner Leistung und auch an den Funktionen der Webplattform.
In Chrome 50 (geschätztes Beta-Datum: 10. bis 17. März) gibt es eine Reihe von Änderungen. Diese Liste kann sich jederzeit ändern.
AppCache in nicht sicheren Kontexten eingestellt
Zusammenfassung: Um Cross-Site-Scripting zu erschweren, stellen wir AppCache für unsichere Ursprünge ein. Wir gehen davon aus, dass es in Chrome 52 nur für Ursprünge funktioniert, die Inhalte über HTTPS bereitstellen.
Entfernung geplant | Chromestatus-Tracker | Chromium-Fehler
AppCache ist eine Funktion, die den Offlinezugriff und dauerhaften Zugriff auf eine Quelle ermöglicht. Dies ist eine effektive Methode zur Rechteausweitung bei einem Cross-Site-Scripting-Angriff. Dies ist Teil eines größeren Projekts, bei dem leistungsstarke Funktionen bei unsicheren Ursprüngen entfernt werden.
Chrome entfernt diesen Angriffsvektor, indem er nur über HTTPS zugelassen wird. Die HTTP-Unterstützung wird in Chrome 50 eingestellt und voraussichtlich in Chrome 52 vollständig entfernt.
Document.defaultCharset wurde entfernt
Zusammenfassung: document.defaultCharset wurde entfernt, um die Einhaltung der Spezifikationen zu verbessern.
Intent to Remove | Chromestatus-Tracker | CRBug-Problem
document.defaultCharset ist eine schreibgeschützte Eigenschaft, die in Chrome 49 eingestellt wurde. Sie gibt die Standardzeichencodierung des Systems des Nutzers basierend auf seinen regionalen Einstellungen zurück. Es hat sich als nicht sinnvoll erwiesen, diesen Wert beizubehalten, da Browser die Informationen zur Zeichencodierung in der HTTP-Antwort oder im in die Seite eingebetteten Meta-Tag verwenden.
Verwenden Sie stattdessen document.characterSet, um den ersten im HTTP-Header angegebenen Wert abzurufen. Wenn das nicht der Fall ist, wird der im Attribut charset des Elements <meta> angegebene Wert verwendet (z. B. <meta
charset="utf-8">). Wenn keines dieser Elemente vorhanden ist, wird document.characterSet als Systemeinstellung des Nutzers verwendet.
Weitere Informationen zu den Gründen, warum wir dies nicht spezifizieren, finden Sie in diesem GitHub-Problem.
Subresource-Attribut aus dem Link-Element entfernt
Zusammenfassung: Der Wert „subresource“ wird für das rel-Attribut von HTMLLinkElement nicht mehr unterstützt.
Entfernung geplant | Chromestatus-Tracker | Chromium-Fehler
Das subresource-Attribut in <link> sollte eine Ressource während der Inaktivität eines Browsers vorab laden. Nachdem ein Browser eine Seite heruntergeladen hat, konnte er dann Ressourcen wie andere Seiten vorab herunterladen, damit sie bei einer Nutzeranfrage einfach aus dem Browsercache abgerufen werden konnten.
Beim Attribut subresource sind einige Probleme aufgetreten. Erstens hat sie nie wie vorgesehen funktioniert. Die referenzierten Ressourcen wurden mit niedriger Priorität heruntergeladen. Das Attribut wurde nie in anderen Browsern als Chrome implementiert. Die Chrome-Implementierung hatte einen Fehler, der dazu führte, dass Ressourcen doppelt heruntergeladen wurden.
Entwickler, die die Nutzerfreundlichkeit durch das Vorabladen von Inhalten verbessern möchten, haben mehrere Möglichkeiten. Die am besten anpassbare Option ist die Erstellung eines Dienst-Workers, um Pre-Caching und die Caches API zu nutzen. Weitere Lösungen sind andere Werte für das rel-Attribut, darunter preconnect, prefetch, preload und prerender. Einige dieser Optionen sind experimentell und werden möglicherweise nicht allgemein unterstützt.
Fallback auf unsichere TLS-Version entfernen
Zusammenfassung: Ein Mechanismus zum Erzwingen von Datenrückgaben über weniger sichere oder unsichere TLS-Versionen wird entfernt.
Entfernung geplant | Chromestatus-Tracker | Chromium-Fehler
TLS (Transport Layer Security) unterstützt einen Mechanismus zur Versionsabsprache, der die Einführung neuer TLS-Versionen ohne Kompatibilitätsprobleme ermöglicht. Einige Server wurden so implementiert, dass Browser unsichere Endpunkte als Fallback verwenden mussten. Dadurch können Angreifer jede Website, nicht nur die falsch konfigurierten, dazu zwingen, schwächere TLS-Versionen auszuhandeln.
Betroffene Websites können keine Verbindung zu ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION herstellen. Administratoren sollten dafür sorgen, dass ihre Serversoftware auf dem neuesten Stand ist. Wenn das Problem weiterhin besteht, wenden Sie sich an den Anbieter der Serversoftware, um zu erfahren, ob es eine Lösung gibt.
KeyboardEvent.prototype.keyLocation entfernen
Zusammenfassung: Entfernen Sie einen nicht benötigten Alias für das Keyboard.prototype.location-Attribut.
Entfernung geplant | Chromestatus-Tracker | Chromium-Fehler
Dieses Attribut ist einfach ein Alias für das Keyboard.prototype.location-Attribut, mit dem Tasten, die sich an mehreren Stellen auf einer Tastatur befinden, eindeutig identifiziert werden können. Mit beiden Attributen können Entwickler beispielsweise zwischen den beiden Enter-Tasten auf einer erweiterten Tastatur unterscheiden.
In RTCPeerConnection-Methoden erforderliche Fehler- und Erfolgs-Handler
Zusammenfassung: Für die WebRTC-RTCPeerConnection-Methoden createOffer() und createAnswer() sind jetzt sowohl ein Fehler- als auch ein Erfolgs-Handler erforderlich. Bisher war es möglich, diese Methoden nur mit einem Erfolgs-Handler aufzurufen. Diese Verwendung ist nicht mehr zulässig.
Entfernung geplant | Chromestatus-Tracker | Chromium-Fehler
In Chrome 49 wird jetzt eine Warnung angezeigt, wenn setLocalDescription() oder setRemoteDescription() aufgerufen wird, ohne dass ein Fehlerhandler angegeben wird. Das Argument „errorHandler“ ist seit Chrome 50 obligatorisch.
Dies ist Teil der Vorbereitung auf die Einführung von Promises für diese Methoden, wie es in der WebRTC-Spezifikation gefordert wird.
Hier ist ein Beispiel aus der WebRTC-RTCPeerConnection-Demo (main.js, Zeile 126):
function onCreateOfferSuccess(desc) {
pc1.setLocalDescription(desc, function() {
onSetLocalSuccess(pc1);
}, onSetSessionDescriptionError);
pc2.setRemoteDescription(desc, function() {
onSetRemoteSuccess(pc2);
}, onSetSessionDescriptionError);
pc2.createAnswer(onCreateAnswerSuccess, onCreateSessionDescriptionError);
}
Sowohl setLocalDescription() als auch setRemoteDescription() haben einen Fehler-Handler. Ältere Browser, die nur einen Erfolgs-Handler erwarten, ignorieren das Argument für den Fehler-Handler einfach, wenn es vorhanden ist. Der Aufruf dieses Codes in einem älteren Browser führt nicht zu einer Ausnahme.
Für Produktions-WebRTC-Anwendungen empfehlen wir im Allgemeinen die Verwendung von adapter.js, einem Shim, der vom WebRTC-Projekt gepflegt wird, um Apps vor Spezifikationsänderungen und Präfixunterschieden zu schützen.
XMLHttpRequestProgressEvent wird nicht mehr unterstützt
Zusammenfassung: Die XMLHttpRequestProgressEvent-Benutzeroberfläche wird zusammen mit den Attributen position und totalSize entfernt.
Entfernung geplant | Chromestatus-Tracker | Chromium-Fehler
Dieses Ereignis wurde zur Unterstützung der Gecko-Kompatibilitätsattribute position und totalSize verwendet. Die Unterstützung für alle drei wurde in Mozilla 22 eingestellt und die Funktion wurde längst durch die ProgressEvent ersetzt.
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
}
}
Prefixed Encrypted Media Extensions entfernen
Zusammenfassung: Verschlüsselte Medienerweiterungen mit Präfix wurden entfernt und durch einen spezifikationsbasierten Ersatz ohne Präfix ersetzt.
Entfernung geplant | Chromestatus-Tracker | Chromium-Fehler
In Chrome 42 haben wir eine spezifikationsbasierte, vorangestellte Version von verschlüsselten Medienerweiterungen eingeführt. Mit dieser API werden Digital Rights Management-Systeme für die Verwendung mit HTMLMediaElement gefunden, ausgewählt und verwendet.
Das war vor fast einem Jahr. Da die Version ohne Präfix mehr Funktionen bietet als die Version mit Präfix, ist es an der Zeit, die Version mit Präfix der API zu entfernen.
Unterstützung für SVGElement.offset-Attribute entfernen
Zusammenfassung: Die Offset-Attribute für SVGElement wurden zugunsten der allgemeiner unterstützten Attribute in HTMLElement eingestellt.
Entfernung geplant | Chromestatus-Tracker | Chromium-Fehler
Offset-Properties werden seit langem sowohl von HTMLElement als auch von SVGElement unterstützt. Gecko und Edge unterstützen sie jedoch nur unter HTMLElement. Um die Konsistenz zwischen Browsern zu verbessern, wurden diese Properties in Chrome 48 eingestellt und werden jetzt entfernt.
Obwohl entsprechende Properties Teil von HTMLElement sind, können Entwickler, die eine Alternative suchen, auch getBoundingClientRect() verwenden.