Dans presque toutes les versions de Chrome, nous constatons un nombre important de mises à jour et d'améliorations du produit, de ses performances et des fonctionnalités de la plate-forme Web. Cet article décrit les abandons et les suppressions dans Chrome 62, qui est en version bêta depuis le 14 septembre. Cette liste est susceptible d'être modifiée à tout moment.
Suppression de RTCPeerConnection.getStreamById()
Il y a près de deux ans, getStreamById() a été supprimé de la spécification WebRTC. La plupart des autres navigateurs l'ont déjà supprimé de leurs implémentations, et la fonctionnalité a été abandonnée dans Chrome 60. Bien que cette fonction soit peu utilisée, il existe également un risque d'interopérabilité mineur avec les navigateurs Edge et basés sur WebKit à l'exception de Safari, où getStreamById() est toujours pris en charge.
Les développeurs qui ont besoin d'une implémentation alternative peuvent trouver un exemple de code dans l'intent de suppression ci-dessous.
Intent to Remove | Chromestatus Tracker | Bug Chromium
Suppression de SharedWorker.workerStart
Cette propriété, qui était destinée à surveiller les performances des travailleurs, a été supprimée de la spécification il y a plus de deux ans et n'est pas compatible avec les autres principaux navigateurs. Une approche plus moderne du suivi des performances d'un worker consiste à utiliser Performance.timing.
Intent to Remove | Chromestatus Tracker | Bug Chromium
Suppression de SVGPathElement.getPathSegAtLength()
Dans Chrome 48, SVGPathElement.pathSegList() et les interfaces associées ont été supprimés conformément à la spécification SVG. À l'époque, cette méthode a été laissée par erreur. Nous ne nous attendons pas à ce que cette suppression casse des pages Web, car, depuis deux ans, elle renvoie un objet qui n'existe plus dans Blink.
Intent to Remove | Chromestatus Tracker | Bug Chromium
Supprimer l'utilisation des notifications à partir d'iFrames non sécurisées
Les demandes d'autorisation des iFrames peuvent prêter à confusion pour les utilisateurs, car il est difficile de faire la distinction entre l'origine de la page contenante et l'origine de l'iFrame qui envoie la requête. Lorsque le champ d'application des demandes n'est pas clair, il est difficile pour les utilisateurs de déterminer s'ils doivent accorder ou refuser l'autorisation.
L'interdiction des notifications dans les iFrames alignera également les exigences concernant l'autorisation de notification sur celles des notifications push, ce qui facilitera les choses pour les développeurs.
Les développeurs qui ont besoin de cette fonctionnalité peuvent ouvrir une nouvelle fenêtre pour demander l'autorisation de notification.