In vrijwel elke versie van Chrome zien we een aanzienlijk aantal updates en verbeteringen aan het product, de prestaties en ook de mogelijkheden van het webplatform.
In Chrome 50 (verwachte bètadatum: 10 tot en met 17 maart) zijn er een aantal wijzigingen in Chrome. Deze lijst kan op elk moment worden gewijzigd.
AppCache is verouderd in onveilige contexten
TL;DR : Om cross-site scripting te voorkomen, schaffen we AppCache af voor onveilige bronnen. We verwachten dat het in Chrome 52 alleen zal werken voor bronnen die content via HTTPS aanbieden.
Intentie tot verwijderen | Chromestatus Tracker | Chromium-bug
AppCache is een functie die offline en permanente toegang tot een bron mogelijk maakt, wat een krachtige privilege-escalatie is voor een cross-site scripting-aanval. Dit is onderdeel van een bredere inspanning om krachtige functies op onveilige bronnen te verwijderen .
Chrome verwijdert deze aanvalsmethode door deze alleen via HTTPS toe te staan. We schaffen HTTP-ondersteuning af in Chrome 50 en verwachten deze volledig te verwijderen in Chrome 52.
Document.defaultCharset is verwijderd
TL;DR : document.defaultCharset is verwijderd om de specificatie-naleving te verbeteren.
Intentie tot verwijderen | Chromestatus Tracker | CRBug-probleem
De document.defaultCharset , die in Chrome 49 is verouderd, is een alleen-lezen eigenschap die de standaardtekencodering van het systeem van de gebruiker retourneert op basis van diens regionale instellingen. Het is niet zinvol gebleken deze waarde te behouden vanwege de manier waarop browsers de tekencoderingsinformatie gebruiken in de HTTP-respons of in de metatag die in de pagina is ingesloten.
Gebruik in plaats daarvan document.characterSet om de eerste waarde op te halen die in de HTTP-header is opgegeven. Als deze niet aanwezig is, wordt de waarde opgehaald die is opgegeven in het charset attribuut van het <meta> -element (bijvoorbeeld <meta charset="utf-8"> ). Als geen van deze beschikbaar is, wordt document.characterSet de systeeminstelling van de gebruiker.
Je kunt meer lezen over de redenering om dit niet te specificeren in dit github-probleem
Subresource-kenmerk verwijderd uit linkelement
TL;DR : Verwijder ondersteuning voor de subresource voor het rel -kenmerk van HTMLLinkElement .
Intentie tot verwijderen | Chromestatus Tracker | Chromium-bug
Het doel van het subresource -attribuut op <link> was om een resource vooraf op te halen tijdens de inactieve tijd van een browser. Nadat een browser een pagina had gedownload, kon deze vervolgens bronnen zoals andere pagina's vooraf downloaden, zodat deze, wanneer ze door gebruikers werden opgevraagd, eenvoudig uit de browsercache konden worden opgehaald.
Het subresource -attribuut kampte met een aantal problemen. Ten eerste werkte het nooit zoals bedoeld. De bronnen waarnaar werd verwezen, werden met lage prioriteit gedownload. Het attribuut werd nooit geïmplementeerd in een andere browser dan Chrome. De Chrome-implementatie had een bug waardoor bronnen twee keer werden gedownload.
Ontwikkelaars die de gebruikerservaring willen verbeteren door content vooraf te laden, hebben een aantal opties. De meest aanpasbare optie is het bouwen van een service worker die gebruikmaakt van precaching en de Caches API. Aanvullende oplossingen omvatten andere waarden voor het rel -kenmerk, waaronder preconnect , prefetch , preload en prerender . Sommige van deze opties zijn experimenteel en worden mogelijk niet breed ondersteund.
Verwijder onveilige TLS-versie fallback
TL;DR : Verwijder een mechanisme waarmee servers gegevens kunnen retourneren met behulp van minder veilige of onveilige versies van TLS.
Intentie tot verwijderen | Chromestatus Tracker | Chromium-bug
Transport Layer Security (TLS) ondersteunt een mechanisme voor het onderhandelen over versies, waardoor nieuwe TLS-versies kunnen worden geïntroduceerd zonder de compatibiliteit te verbreken. Sommige servers hebben dit zo geïmplementeerd dat browsers onveilige eindpunten als fallback moesten gebruiken. Hierdoor konden aanvallers elke website, niet alleen websites die onjuist geconfigureerd zijn, dwingen om te onderhandelen over zwakkere versies van TLS.
Getroffen sites kunnen geen verbinding maken met ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION . Beheerders moeten ervoor zorgen dat hun serversoftware up-to-date is. Als het probleem nog steeds niet is opgelost, neem dan contact op met de leverancier van de serversoftware om te zien of er een oplossing beschikbaar is.
Verwijder KeyboardEvent.prototype.keyLocation
TL;DR : Verwijder een onnodige alias voor het kenmerk Keyboard.prototype.location .
Intentie tot verwijderen | Chromestatus Tracker | Chromium-bug
Dit kenmerk is simpelweg een alias voor het kenmerk Keyboard.prototype.location , waarmee onderscheid kan worden gemaakt tussen toetsen die zich op meerdere plaatsen op een toetsenbord bevinden. Beide kenmerken stellen ontwikkelaars bijvoorbeeld in staat om onderscheid te maken tussen de twee Enter -toetsen op een uitgebreid toetsenbord.
Fout- en succeshandlers vereist in RTCPeerConnection-methoden
TL;DR : De WebRTC RTCPeerConnection-methoden createOffer() en createAnswer() vereisen nu zowel een error handler als een success handler. Voorheen was het mogelijk om deze methoden aan te roepen met alleen een success handler. Dit gebruik is verouderd.
Intentie tot verwijderen | Chromestatus Tracker | Chromium-bug
In Chrome 49 hebben we een waarschuwing toegevoegd als je setLocalDescription() of setRemoteDescription() aanroept zonder een foutafhandelingsfunctie mee te geven. Het argument voor de foutafhandelingsfunctie is verplicht vanaf Chrome 50.
Dit maakt deel uit van het vrijmaken van de weg voor het introduceren van beloftes op deze methoden, zoals vereist door de WebRTC-specificatie .
Hier is een voorbeeld uit de WebRTC RTCPeerConnection-demo ( main.js, regel 126 ):
function onCreateOfferSuccess(desc) {
pc1.setLocalDescription(desc, function() {
onSetLocalSuccess(pc1);
}, onSetSessionDescriptionError);
pc2.setRemoteDescription(desc, function() {
onSetRemoteSuccess(pc2);
}, onSetSessionDescriptionError);
pc2.createAnswer(onCreateAnswerSuccess, onCreateSessionDescriptionError);
}
Merk op dat zowel setLocalDescription() als setRemoteDescription() een error handler hebben. Oudere browsers die alleen een success handler verwachten, negeren het error handler argument als het aanwezig is; het aanroepen van deze code in een oudere browser veroorzaakt geen uitzondering.
Over het algemeen raden we u aan om voor WebRTC-productietoepassingen adapter.js te gebruiken. Dit is een shim die wordt onderhouden door het WebRTC-project. Hiermee kunt u apps beschermen tegen specificatiewijzigingen en prefixverschillen.
De XMLHttpRequestProgressEvent wordt niet langer ondersteund
TL;DR : De XMLHttpRequestProgressEvent -interface wordt verwijderd, samen met de kenmerken position en totalSize .
Intentie tot verwijderen | Chromestatus Tracker | Chromium-bug
Deze gebeurtenis bestond ter ondersteuning van de Gecko-compatibiliteitseigenschappen position en totalSize . Ondersteuning voor alle drie is in Mozilla 22 stopgezet en de functionaliteit is al lang vervangen door 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
}
}
Verwijder vooraf toegevoegde gecodeerde media-extensies
TL;DR : Vooraf toegevoegde gecodeerde media-extensies zijn verwijderd ten gunste van een op specificaties gebaseerde vervanging zonder voorvoegsel.
Intentie tot verwijderen | Chromestatus Tracker | Chromium-bug
In Chrome 42 hebben we een specificatiegebaseerde , niet-geprefixte versie van versleutelde media-extensies uitgebracht. Deze API wordt gebruikt om Digital Rights Management-systemen te detecteren, selecteren en ermee te communiceren voor gebruik met HTMLMediaElement .
Dat was bijna een jaar geleden. En aangezien de versie zonder prefix meer mogelijkheden heeft dan de versie met prefix, is het tijd om de versie met prefix van de API te verwijderen.
Verwijder ondersteuning voor SVGElement.offset-eigenschappen
TL;DR : Offset-eigenschappen voor SVGElement zijn verwijderd ten gunste van de breder ondersteunde eigenschappen voor HTMLElement .
Intentie tot verwijderen | Chromestatus Tracker | Chromium-bug
Offset-eigenschappen worden al lang ondersteund door zowel HTMLElement als SVGElement ; Gecko en Edge ondersteunen ze echter alleen op HTMLElement . Om de consistentie tussen browsers te verbeteren, zijn deze eigenschappen in Chrome 48 verouderd en worden ze nu verwijderd.
Hoewel equivalente eigenschappen deel uitmaken van HTMLElement , kunnen ontwikkelaars die op zoek zijn naar een alternatief ook getBoundingClientRect() gebruiken