Interdire la méthode XMLHTTPRequest() synchrone dans les pages de fermeture
Chrome interdit désormais les appels synchrones à XMLHTTPRequest() lors de la fermeture de la page lorsque celle-ci est quittée ou fermée par l'utilisateur.
Cela s'applique à beforeunload, unload, pagehide et visibilitychange.
Pour vous assurer que les données sont envoyées au serveur lorsqu'une page est déchargée, nous vous recommandons d'utiliser sendBeacon() ou Fetch keep-alive. Pour l'instant, les utilisateurs de la version Enterprise peuvent utiliser l'indicateur de règle AllowSyncXHRInPageDismissal et les développeurs peuvent utiliser l'indicateur d'évaluation d'origine allow-sync-xhr-in-page-dismissal pour autoriser les requêtes XHR synchrones lors du déchargement de la page. Il s'agit d'une mesure de désactivation temporaire, que nous prévoyons de supprimer dans Chrome 88.
Pour en savoir plus à ce sujet et sur les alternatives, consultez Interdire la requête XMLHTTPRequest() synchrone pendant la fermeture de la page.
Intention de suppression | État de la plate-forme Chrome | Bug Chromium
Abandon du protocole FTP
La mise en œuvre actuelle du protocole FTP dans Chrome n'est pas compatible avec les connexions chiffrées (FTPS) ni avec les proxys. L'utilisation du protocole FTP dans le navigateur est suffisamment faible pour qu'il ne soit plus viable d'investir dans l'amélioration du client FTP existant. En outre, des clients FTP plus performants sont disponibles sur toutes les plates-formes concernées.
Chrome 72 ne permet plus d'extraire les sous-ressources de document via FTP et d'afficher les ressources FTP de premier niveau. Actuellement, l'accès aux URL FTP se traduit par l'affichage d'une liste de répertoires ou d'un téléchargement en fonction du type de ressource. En raison d'un bug dans Google Chrome 74 et versions ultérieures, la prise en charge de l'accès aux URL FTP via les proxys HTTP a été abandonnée. La prise en charge du proxy pour FTP a été totalement supprimée dans Google Chrome 76.
Les fonctionnalités restantes de l'implémentation FTP de Google Chrome sont limitées à l'affichage d'un annuaire ou au téléchargement d'une ressource via des connexions non chiffrées.
Le calendrier d'abandon est provisoirement défini comme suit:
Chrome 80 (stable en février 2020)
Le protocole FTP est désactivé par défaut pour les clients non professionnels, mais peut être activé à l'aide des options de ligne de commande --enable-ftp ou --enable-features=FtpProtocol. Vous pouvez également l'activer à l'aide de l'option #enable-ftp sur chrome://flags.
Chrome 81 (stable en mars 2020)
Le protocole FTP est désactivé par défaut pour toutes les installations de Chrome, mais peut être activé à l'aide des indicateurs de ligne de commande --enable-ftp ou --enable-features=FtpProtocol.
Chrome 82 (stable en avril 2020)
Le protocole FTP ne sera plus pris en charge.
Intention de suppression | État de la plate-forme Chrome | Bug Chromium
Interdire les pop-ups d'autorisation pendant le déchargement de la page
Les pages ne peuvent plus utiliser window.open() pour ouvrir une nouvelle page pendant le déchargement. La fonctionnalité de blocage des pop-up de Chrome l'interdit déjà, mais il est désormais interdit, qu'elle soit activée ou non.
Les entreprises peuvent utiliser l'option de règle AllowPopupsDuringPageUnload pour autoriser les pop-ups lors du déchargement. Chrome prévoit de supprimer cet indicateur dans Chrome 82.
Intention de suppression | Outil de suivi Chromestatus | Bug Chromium
Suppression de la sérialisation et du transfert ImageBitmap non propres à l'origine
Des erreurs sont désormais générées lorsqu'un script tente de sérialiser ou de transférer un ImageBitmap dont l'origine n'est pas nettoyée. Un ImageBitmap non propre à l'origine est un objet qui contient des données provenant d'images multi-origines non validées par la logique CORS.
Intention de suppression | État de la plate-forme Chrome | Bug Chromium
La gestion des protocoles nécessite désormais un contexte sécurisé
Les méthodes registerProtocolHandler() et unregisterProtocolHandler() nécessitent désormais un contexte sécurisé. Ces méthodes sont capables de reconfigurer les états client de manière à autoriser la transmission de données potentiellement sensibles sur un réseau.
La méthode registerProtocolHandler() permet à une page Web de s'enregistrer afin de gérer un protocole une fois que l'utilisateur a donné son consentement. Par exemple, une application de messagerie Web peut s'enregistrer pour gérer le schéma mailto:. La méthode unregisterProtocolHandler() correspondante permet à un site d'abandonner son enregistrement lié à la gestion du protocole.
Intention de suppression | État de la plate-forme Chrome | Bug Chromium
Web Components v0 supprimé
Les composants Web v0 ont été supprimés de Chrome. Les API Web Components v1 constituent une norme de plate-forme Web qui sera disponible dans Chrome, Safari, Firefox et (bientôt) Edge. Pour obtenir des conseils sur la mise à niveau, consultez Mise à jour de Web Components: plus de temps pour passer aux API v1. Les fonctionnalités suivantes ont été supprimées. Cet abandon concerne les éléments listés ci-dessous.
Éléments personnalisés
Intention de suppression | État de la plate-forme Chrome | Bug Chromium
Importations HTML
Intention de suppression | État de la plate-forme Chrome | Bug Chromium
Shadow DOM
Intention de suppression | État de la plate-forme Chrome | Bug Chromium
Suppression de -webkit-appearance:button pour les éléments arbitraires.
Modification de -webkit-appearance:button pour qu'il fonctionne uniquement avec les boutons <button> et <input>. Si button est spécifié pour un élément non compatible, l'élément a l'apparence par défaut. Tous les autres mots clés -webkit-appearance sont déjà soumis à cette restriction.
Intention de suppression | État de la plate-forme Chrome | Bug Chromium
Règlement relatif aux abandons
Pour que la plate-forme reste opérationnelle, nous supprimons parfois de la plate-forme Web les API qui ont fait leurs preuves. Nous pouvons supprimer une API pour de nombreuses raisons, par exemple:
- Elles sont remplacées par des API plus récentes.
- Ils sont mis à jour pour refléter les modifications apportées aux spécifications, afin d'assurer leur cohérence et leur alignement avec les autres navigateurs.
- Il s'agit des premiers tests qui n'ont jamais abouti dans d'autres navigateurs et qui peuvent donc alourdir la charge de travail des développeurs Web.
Certaines de ces modifications auront une incidence sur un très petit nombre de sites. Pour limiter ces problèmes à l'avance, nous essayons d'en informer les développeurs au préalable afin qu'ils puissent apporter les modifications nécessaires afin que leurs sites continuent de fonctionner.
Chrome dispose actuellement d'un processus d'abandon et de suppression des API, essentiellement:
- Faites des annonces à la liste de diffusion blink-dev.
- Définissez des avertissements et des échelles de temps dans la console des outils pour les développeurs Chrome lorsque l'utilisation est détectée sur la page.
- Attendez, surveillez la fonctionnalité, puis supprimez-la lorsque son utilisation diminue.
Vous pouvez trouver une liste de toutes les fonctionnalités obsolètes sur chromestatus.com à l'aide du filtre obsolète et des fonctionnalités supprimées en appliquant le filtre supprimé. Nous essaierons également de résumer certains des changements, raisonnements et parcours de migration présentés dans ces posts.