Beëindigingen en verwijderingen in Chrome 60

Joe Medley
Joe Medley

In bijna elke versie van Chrome zien we een aanzienlijk aantal updates en verbeteringen aan het product, de prestaties ervan en ook de mogelijkheden van het webplatform. In dit artikel worden de beëindigingen en verwijderingen beschreven van Chrome 60, dat vanaf 8 juni in bèta is. Deze lijst kan op elk moment worden gewijzigd.

Beveiliging

crypto.subtle vereist nu een veilige oorsprong

De Web Crypto API die wordt ondersteund sinds Chrome 37 heeft altijd gewerkt op niet-beveiligde bronnen. Vanwege het al lang bestaande beleid van Chrome om veilige oorsprong te verkiezen boven krachtige functies , is crypto.subtle niet alleen zichtbaar op veilige oorsprong.

Intentie om te verwijderen | Chroombug

Verwijder door inhoud geïnitieerde topframenavigaties naar gegevens-URL's

Omdat ze onbekend zijn bij niet-technische browsergebruikers, zien we steeds vaker dat deze data: worden gebruikt bij spoofing- en phishing-aanvallen. Om dit te voorkomen, blokkeren we het laden van data: URL's in het bovenste frame. Dit is van toepassing op <a> tags, window.open , window.location en soortgelijke mechanismen. Het data: -schema werkt nog steeds voor bronnen die door een pagina worden geladen.

Deze functie is verouderd in Chrome 58 en is nu verwijderd.

Intentie om te verwijderen | Chromestatustracker | Chroombug

Schakel navigator.sendBeacon() tijdelijk uit voor sommige blobs

De functie navigator.sendBeacon() is beschikbaar sinds Chrome 39 . Zoals oorspronkelijk geïmplementeerd, kan het data argument van de functie elke willekeurige blob bevatten waarvan het type niet op de CORS-veilige lijst staat. Wij zijn van mening dat dit een potentiële bedreiging voor de veiligheid is, hoewel nog niemand heeft geprobeerd hier misbruik van te maken. Omdat we er GEEN redelijke onmiddellijke oplossing voor hebben, kan sendBeacon() tijdelijk niet langer worden aangeroepen op blobs waarvan het type NIET op de CORS-veilige lijst staat.

Hoewel deze wijziging is doorgevoerd voor Chrome 60, is deze sindsdien weer samengevoegd met Chrome 59.

Chroombug

CSS

Zorg ervoor dat de schaduwdoordringende afstammelingscombinator zich gedraagt ​​als afstammelingencombinator

De schaduwdoordringende afstammelingscombinator ( >>> ), onderdeel van CSS Scoping Module Level 1 , was bedoeld om de kinderen van een bepaald voorouderelement te matchen, zelfs als ze in een schaduwboom verschenen. Dit had enkele beperkingen. Ten eerste kon het volgens de specificaties alleen worden gebruikt in JavaScript-aanroepen zoals querySelector() en werkte het niet in stylesheets. Belangrijker nog was dat browserleveranciers het niet konden laten werken voorbij één niveau van de Shadow DOM.

Bijgevolg is de afstammelingencombinator verwijderd uit relevante specificaties, waaronder Shadow DOM v1. In plaats van webpagina's te verbreken door deze selector uit Chromium te verwijderen, hebben we ervoor gekozen om de schaduwdoordringende afstammeling-combinator een alias te geven aan de afstammeling-combinator. Het oorspronkelijke gedrag is verouderd in Chrome 45 . Het nieuwe gedrag is geïmplementeerd in Chrome 61.

Intentie om te verwijderen | Chromestatustracker | Chroombug

JavaScript

Beëindig en verwijder RTCPeerConnection.getStreamById()

Bijna twee jaar geleden werd getStreamById() verwijderd uit de WebRTC-specificatie . De meeste andere browsers hebben dit al uit hun implementaties verwijderd. Hoewel wordt aangenomen dat deze functie weinig wordt gebruikt, wordt er ook aangenomen dat er een klein interoperabiliteitsrisico bestaat met andere Edge- en WebKit-gebaseerde browsers dan Safari, waar getStreamById() nog steeds wordt ondersteund. Ontwikkelaars die een alternatieve implementatie nodig hebben, kunnen voorbeeldcode vinden in de Intentie om te verwijderen hieronder.

Verwijdering vindt plaats in Chrome 62.

Intentie om te verwijderen | Chromestatustracker | Chroombug

SVGPathElement.getPathSegAtLength afschaffen

Meer dan twee jaar geleden werd getPathSegAtLength() verwijderd uit de SVG-specificatie . Omdat er in httparchive slechts een handvol treffers voor deze methode zijn, wordt deze in Chrome 60 verouderd. De verwijdering zal naar verwachting plaatsvinden in Chrome 62, dat ergens begin of midden oktober zal verschijnen.

Intentie om af te schaffen | Chromestatustracker | Chroombug

Verplaats getContextAttributes() achter een vlag

De functie getContextAttributes() wordt sinds 2013 ondersteund op CanvasRenderingContext2D . De functie maakte echter geen deel uit van een standaard en is sindsdien geen onderdeel meer geworden van een standaard. Het had geïmplementeerd moeten worden achter de opdrachtregelvlag --enable-experimental-canvas-features , maar dat gebeurde ten onrechte niet. In Chrome 60 is dit toezicht gecorrigeerd. Er wordt aangenomen dat deze wijziging veilig is, omdat er geen gegevens zijn die aantonen dat iemand de methode gebruikt.

Chroombug

Verwijder Headers.prototype.getAll()

De functie Headers.prototype.getAll() wordt verwijderd volgens de nieuwste versie van de Fetch-specificatie .

Intentie om te verwijderen | Chromestatustracker | Chroombug

IndexedDB.webkitGetDatabaseNames() verwijderen

We hebben deze functie toegevoegd toen geïndexeerde database relatief nieuw was in Chrome en voorvoegsels een rage waren. De API retourneert asynchroon een lijst met bestaande databasenamen in een oorsprong, wat verstandig genoeg leek.

Helaas is het ontwerp gebrekkig, in die zin dat de resultaten verouderd kunnen zijn zodra ze worden geretourneerd, zodat het eigenlijk alleen kan worden gebruikt voor loggen, en niet voor serieuze applicatielogica. Het github-probleem volgt/linkt naar eerdere discussies over alternatieven, die een andere aanpak zouden vereisen. Hoewel er af en toe interesse was bij ontwikkelaars, is het probleem, gezien het gebrek aan cross-browser vooruitgang, door bibliotheekauteurs opgelost.

Ontwikkelaars die deze functionaliteit nodig hebben, moeten hun eigen oplossing ontwikkelen. Bibliotheken zoals Dexie.js gebruiken bijvoorbeeld een globale tabel die zelf een andere database is om de namen van databases bij te houden.

Deze functie is verouderd in Chrome 58 en is nu verwijderd.

Intentie om te verwijderen | Chromestatustracker | Chroombug

Verwijder WEBKIT_KEYFRAMES_RULE en WEBKIT_KEYFRAME_RULE

De niet-standaard WEBKIT_KEYFRAMES_RULE en WEBKIT_KEYFRAME_RULE constanten worden verwijderd uit CSS-regel . Ontwikkelaars moeten in plaats daarvan KEYFRAMES_RULE en KEYFRAME_RULE gebruiken.

Intentie om te verwijderen | Chromestatustracker | Chroombug

Gebruikersomgeving

Vereist gebruikersgebaar voor dialoogvensters vóór het laden

Vanaf Chrome 60 wordt het dialoogvenster beforeunload ' alleen weergegeven als het frame dat het probeert weer te geven een gebruikersgebaar of gebruikersinteractie heeft ontvangen (of als een ingebed frame een dergelijk gebaar heeft ontvangen). Voor alle duidelijkheid: dit is geen wijziging in de verzending van de beforeunload gebeurtenis. Het is slechts een wijziging in de vraag of het dialoogvenster wordt weergegeven.

Het dialoogvenster beforeunload is een app-modaal dialoogvenster. Als zodanig is het inherent gebruikersvijandig, wat betekent dat het reageert op gebruikersnavigatie door de beslissing van de gebruiker in twijfel te trekken. Er zijn positieve toepassingen voor deze functie. Het wordt bijvoorbeeld vaak gebruikt om gebruikers te waarschuwen wanneer ze gegevens verliezen door te navigeren.

Hoewel de mogelijkheid voor een pagina om tekst te leveren voor het beforeunload dialoogvenster een tijdje geleden is verwijderd, blijven beforeunload dialogen een vector van misbruik. Met name de beforeunload -dialogen zijn een onderdeel van oplichtingswebsites, waar autoplay-audio en bedreigende tekst een context bieden waarin het door Chromium verstrekte bericht 'Weet je zeker dat je deze pagina wilt verlaten' zorgwekkend wordt.

We willen de naald inrijgen en alleen goed gebruik van het dialoogvenster beforeunload toestaan. Goed gebruik van de dialoog is die waarbij de gebruiker een status heeft die mogelijk verloren gaat. Als de gebruiker nooit interactie heeft gehad met de pagina, kan de gebruiker geen enkele status hebben die verloren kan gaan. Daarom riskeren we in dat geval geen verlies van gebruikersgegevens door de dialoog te onderdrukken.