Choix de mots sur la prochaine dépréciation des boîtes de dialogue JavaScript

De nombreux nouveaux arrivants JavaScript commencent par cette ligne simple:

 alert ("bonjour, monde");

Cependant, la récente élimination de Chrome de la fonctionnalité alert() dans les iframes d'origine transversale a provoqué des problèmes généralisés, comme en témoignent une vague de billets de support Codepen. Cette modification, ainsi que la dépréciation d'autres boîtes de dialogue JavaScript natives comme confirm() , prompt() et onbeforeunload , ont un impact significatif sur des sites Web comme Codepen qui s'appuient fortement sur les iframes d'origine inter-originaux pour la sécurité. L'absence d'avertissement antérieur a ajouté à la frustration.

Bien que les préoccupations de sécurité soient compréhensibles (les dialogues JavaScript semblent identiques quelle que soit l'origine, les utilisateurs potentiellement confus), le changement brutal surplombe les solutions existantes comme le sable.<iframe sandbox=""></iframe> Fournit une sécurité robuste, permettant à des fonctionnalités spécifiques d'être activées sélectivement (<iframe sandbox="allow-scripts allow-downloads ...etc"></iframe> ). L'attribut allow-modals existant semble insuffisant, suggérant un objectif plus large: la suppression complète des boîtes de dialogue JavaScript à partir de la plate-forme Web.

Cette mesure drastique briserait d'innombrables tutoriels et applications. Bien que la restriction de l'origine croisée soit retardée jusqu'en janvier 2022, la suppression complète prévue, soutenue par Chrome, Firefox et Safari, est profondément préoccupante. L'absence de consultation suffisante des développeurs et des utilisateurs est une critique majeure.

L'alternative suggérée, postMessage , présente plusieurs inconvénients:

1. Comportement non bloquant: Contrairement à la boîte de dialogue JavaScript, postMessage n'arrête pas l'exécution, modifiant le flux d'application.
2. Injection de code: Obliger les développeurs à injecter du code dans le code utilisateur introduit une dette technique et des effets secondaires inattendus (par exemple, modification du comportement du sélecteur CSS).
3. Risques de sécurité: le passage des données générées par l'utilisateur au cadre parent présente des vulnérabilités potentielles XSS.

Encore des solutions de contournement plus simples, comme window.alert = console.log , partagez des problèmes similaires.

De nombreux développeurs ont exprimé des préoccupations:

• Jaden Baptista: suggère de contenir l'alerte dans l'Iframe lui-même, améliorant à la fois la sécurité et l'UX.
• Matthew Phillips: Critique la décision comme hiérarchiser certains sites Web sur d'autres.
• Dan Abramov: exprime ses inquiétudes quant au manque de respect des cas d'utilisation existants et de la complexité de mise en œuvre.
• Ben Lesh: souligne que certaines applications utilisent la nature bloquante d' alert() comme une fonctionnalité (par exemple, des jeux en pause).

La métrique citée de 0,006% des pages vues utilisant ces fonctions dans les iframes d'origine transversale est trompeuse, comme le souligne Dan Abramov: les fonctionnalités critiques, telles que les flux de suppression du compte, peuvent ne pas être accessibles fréquemment mais sont néanmoins essentielles.

Chris Ferdinandi et Jeremy Keith soulignent en outre le manque de communication et l'impact significatif sur le développement Web. Les réponses condescendantes de certains au sein de Google ne font qu'exacerber le problème.

Tout en reconnaissant les contributions de Google à l'avancement du Web, la critique se concentre sur le manque de sensibilisation des développeurs et des utilisateurs, une discussion insuffisante sur les implications et les stratégies de transition, et un manque d'ouverture à l'ajustement de l'action. Des processus plus collaboratifs et transparents sont cruciaux pour les futurs changements de plate-forme Web.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!