Podría ser lo primero que mucha gente aprenda en JavaScript:
alert("Hello, World");Un día en CodePen, nos despertamos con una tonelada de tickets de atención al cliente sobre la rotura de sus bolígrafos, lo que finalmente se redujo a una versión de Chrome que se envió donde se rompieron. alert() del funcionamiento en iframes de origen cruzado. Y todos los demás “Diálogos de JavaScript” nativos, como confirm(), prompt() y no sé qué másonbeforeunload?, .htpasswd activos protegidos?).
Los iframes de origen cruzado son esencialmente el corazón del funcionamiento de CodePen. Usted escribe código y lo ejecutamos por usted en un iframe que no comparte el mismo dominio que CodePen, como la primera línea de defensa de seguridad. No escuchamos ningún aviso ni nada, pero estoy seguro de que los planos estaban a la vista.
Yo tuiteé por consternación. Entiendo que hay posibles problemas de seguridad aquí. Los cuadros de diálogo de JavaScript tienen el mismo aspecto tanto si son activados por un iframe como si no, por lo que aparentemente es confuso en el mejor de los casos cuando son activados por un iframe, particularmente un iframe de origen cruzado donde la página principal probablemente tiene poco control. Bueno, fuera de, ya sabes, un sitio web como CodePen. Chrome también menciona problemas de rendimiento, ya que la naturaleza de estos cuadros de diálogo de JavaScript es que bloquean el hilo principal cuando están abiertos, lo que básicamente detiene todo.
Sin embargo, hay todo tipo de problemas de seguridad y molestias de UX que pueden provenir de iframes. Es por eso que el sandboxing es una cosa. Puedo hacer esto:
<iframe sandbox></iframe>Y ese tonto está encerrado. Si algún formulario intentó enviar algo allí: no, no funcionará. ¿Qué pasa si intenta activar una descarga? No. ¿Solicitar acceso al dispositivo? De ninguna manera. Ni siquiera puede cargar JavaScript en absoluto. Eso es a menos que lo deje:
<iframe sandbox="allow-scripts allow-downloads ...etc"></iframe>Entonces, ¿por qué no un atributo para los cuadros de diálogo de JavaScript? Irónicamente, ya hay uno: allow-modals. No estoy del todo seguro de por qué eso no es lo suficientemente bueno, pero según tengo entendido, bombardear los diálogos de JavaScript en iframes de origen cruzado es solo un trampolín hacia el objetivo final: eliminándolos de la plataforma web por completo.
Daaaaaang. ¿Enteramente? Esa es la palabra. Imagínese la cantidad de tutoriales de programación que simplemente se romperán por completo.
Por ahora, incluso la eliminación de origen cruzado se retrasa hasta enero de 2022, pero hasta donde sabemos, esto continuará, y luego se realizarán los pasos posteriores para eliminarlos por completo. Esto está encabezado por Chrome, pero el estado informa que tanto Firefox como Safari están de acuerdo con el cambio. Además, este es un cambio específico, así que supongo que podemos mover nuestros dedos literalmente en todas partes aquí, si usted, como yo, siente que esto no fue particularmente bien manejado.
Lo que nos han dicho hasta ahora, la solución es usar postMessage si realmente necesita mantener esta funcionalidad para iframes de origen cruzado. Eso envía la cadena que el usuario usa en window.alert hasta la página principal y activa la alerta desde allí. No soy el mayor fan aquí, porque:
postMessageno bloquea como los diálogos de JavaScript. Esto cambia el flujo de la aplicación.- Tengo que inyectar código en el código de los usuarios para esto. Se trata de una nueva deuda técnica y puede dañar las expectativas de la producción esperada de los usuarios (por ejemplo, una
<script>en su HTML tiene implicaciones extrañas, como cambiar lo que:nth-childy amigos seleccionan). - En general, me preocupa pasar cualquier cosa generada por el usuario a un padre para que la ejecute. Estoy seguro de que hay formas teóricas de hacerlo de forma segura, pero los vectores de ataque XSS siempre sorprenden por su ingenio.
Incluso sugerencias de menor importancia, como window.alert = console.log, tienen esencialmente los mismos problemas.
Permíteme entregar el micrófono a otros para que opinen.
¿No podría la alerta estar contenida en el iframe en lugar de aparecer en la ventana principal?
Jaden Baptista, Gorjeo
¡Sí, por favor! ¿No resuelve eso una gran parte de esto? ¿Haciendo que la UX de estos diálogos sea más útil? Ponga los diálogos dentro de la <iframe>.
“No rompas la red”. a “No rompa el 90% de la Web”. y ahora “No rompa la Web con cuyo contenido estamos de acuerdo”.
Matthew Phillips, Gorjeo
Respeto el deseo de deshacerme de las partes poco elegantes. [of the HTML spec] que pueden verse como errores históricos y que causan complejidad en la implementación, pero no puedo evitar la sensación de que los casos de uso existentes se tratan con muy poco respeto o curiosidad.
Dan Abramov, Gorjeo
Es extraño para mí que esto sea parte de la especificación HTML, no la especificación JavaScript. ¡¿Correcto?!
¿Siempre pensé que había una especie de “directiva principal” para no romper la red? Literalmente he visto juegos basados en la web que usaban alert como una “pausa”, aprovechando la naturaleza de bloqueo como una característica. Me gusta: <button onclick="alert('paused')">Pause</button>[.] Gracioso, pero cierto.
Ben Lesh, Gorjeo
Se citó una métrica de que solo el 0,006% de todas las páginas vistas contienen un iframe de origen cruzado que utiliza estas funciones, sin embargo:
Parece una métrica engañosa para algo como confirm(). Por ejemplo, si el flujo de eliminación de la cuenta está usando confirm() y se rompe debido a un cambio, esto no significa que el flujo de eliminación de la cuenta no sea importante. Simplemente significa que la gente no lo usa en todas las sesiones.
Dan Abramov, Gorjeo
Eso es lo que más me preocupa: alert() es una cosa, pero confirm() literalmente regresa true o false, lo que significa que es una estructura de control lógica en un programa. Eliminar eso rompe sitios web, sin duda. Chris Ferdinandi me mostró este pequeño y oscuro sitio web que lo usa:
Hablando de Chris:
El condescendiente “¿realmente lo leíste, es tan claro?” Es condescendiente AF. Es el equivalente de “solo” o “simplemente” en la documentación del desarrollador.
Lo leí. No lo entendí. Es por eso que le pregunté a alguien cuyo trabajo literal es comunicarse con los desarrolladores sobre los cambios que Chrome realiza en la plataforma.
Esto no es exclusivo de un desarrollador en Chrome. Todo el hilo de mensajes en el que surgió este cambio está lleno de personas que le ruegan a Chrome que no avance con esta propuesta porque romperá todas las cosas.
Chris Ferdinandi, “Google frente a la Web”
Y aquí está Jeremy:
[…] los cambios importantes no ocurren a menudo en la web. Son, y deberían ser, raros. Si eso cambiara, la web sufriría enormemente en términos de previsibilidad.
En segundo lugar, los desarrolladores web no tienen la responsabilidad de realizar un seguimiento de las funciones más antiguas en peligro de quedar obsoletas. Eso depende de los fabricantes de navegadores. Espero sinceramente que no se espere que consultemos un sitio llamado canistilluse.com.
Jeremy Keith, “Fundaciones”
He pintado un cuadro bastante sombrío aquí. Para ser justos, hubo algunos tweets con el Sí !! ¡¡Por fin!! vibra, pero no me parecieron evaluaciones críticas tanto como porristas aleatorias de Google.
Lo crea o no, generalmente soy fanático de Google y creo que hacen un buen trabajo impulsando la web. También creo que es apropiado mover los dedos cuando veo problemas y les pido que mejoren. “Mejor” aquí significa mucho más alcance para desarrolladores y usuarios para explicar la situación, más conversación sobre las posibles implicaciones e ideas de transición, y mucha más apertura para cambiar el rumbo por delante.