Bajas y eliminaciones en Chrome 60

Joe Medley
Joe Medley

En casi todas las versiones de Chrome, vemos una cantidad significativa de actualizaciones y mejoras en el producto, su rendimiento y también en las capacidades de la plataforma web. En este artículo, se describen las bajas y las eliminaciones de Chrome 60, que se encuentra en versión beta desde el 8 de junio. Esta lista está sujeta a cambios en cualquier momento.

Seguridad

crypto.subtle ahora requiere un origen seguro

La API de Web Crypto, que es compatible desde Chrome 37, siempre funcionó en orígenes no seguros. Debido a la política de Chrome de preferir orígenes seguros para funciones potentes, crypto.subtle no solo es visible en orígenes seguros.

Intent to Remove | Error de Chromium

Se quitaron las navegaciones del marco superior iniciadas por el contenido a las URLs de datos.

Debido a que los usuarios de navegadores no técnicos no están familiarizados con ellos, cada vez más vemos que el esquema data: se usa en ataques de falsificación y phishing. Para evitar esto, bloqueamos las páginas web para que no carguen URLs de data: en el marco superior. Esto se aplica a las etiquetas <a>, window.open, window.location y mecanismos similares. El esquema data: seguirá funcionando para los recursos que cargue una página.

Esta función dejó de estar disponible en Chrome 58 y ahora se quitó.

Intento de eliminación | Chromestatus Tracker | Error de Chromium

Inhabilita temporalmente navigator.sendBeacon() para algunos blobs

La función navigator.sendBeacon() está disponible desde Chrome 39. Tal como se implementó originalmente, el argumento data de la función podría contener cualquier blob arbitrario cuyo tipo no esté en la lista segura de CORS. Creemos que esta es una posible amenaza de seguridad, aunque aún nadie intentó aprovecharla. Debido a que NO tenemos una solución inmediata razonable, temporalmente, sendBeacon() ya no se puede invocar en blobs cuyo tipo NO esté en la lista de entidades seguras de CORS.

Aunque este cambio se implementó en Chrome 60, se volvió a combinar con Chrome 59.

Error de Chromium

CSS

Hacer que el combinador de descendientes que atraviesa sombras se comporte como el combinador de descendientes

El combinador de descendientes que atraviesa sombras (>>>), parte del nivel 1 del módulo de alcance de CSS, tenía como objetivo hacer coincidir los elementos secundarios de un elemento ancestro en particular, incluso cuando aparecían dentro de un árbol de sombras. Esto tenía algunas limitaciones. En primer lugar, según las especificaciones, solo se podía usar en llamadas a JavaScript, como querySelector(), y no funcionaba en los diseños de plantillas. Lo más importante es que los proveedores de navegadores no pudieron hacer que funcionara más allá de un nivel del DOM sombreado.

Por lo tanto, se quitó el combinador de descendientes de las especificaciones relevantes, incluido Shadow DOM v1. En lugar de quitar este selector de Chromium para romper las páginas web, elegimos asignar un alias al combinador descendente que atraviesa sombras al combinador descendente. El comportamiento original dejó de estar disponible en Chrome 45. El nuevo comportamiento se implementa en Chrome 61.

Intento de eliminación | Chromestatus Tracker | Error de Chromium

JavaScript

Baja y quita RTCPeerConnection.getStreamById().

Hace casi dos años, getStreamById() se quitó de la especificación de WebRTC. La mayoría de los otros navegadores ya lo quitaron de sus implementaciones. Si bien se cree que esta función se usa poco, también se cree que existe un riesgo menor de interoperabilidad con Edge y los navegadores basados en WebKit excepto Safari, donde getStreamById() aún es compatible. Los desarrolladores que necesiten una implementación alternativa pueden encontrar un código de ejemplo en el Intento de eliminación que se incluye a continuación.

La eliminación se encuentra en Chrome 62.

Intento de eliminación | Chromestatus Tracker | Error de Chromium

Se dio de baja SVGPathElement.getPathSegAtLength

Hace más de dos años, getPathSegAtLength() se quitó de la especificación de SVG. Como solo hay unos pocos hits para este método en httparchive, dejará de estar disponible en Chrome 60. Se espera que la eliminación se realice en Chrome 62, que se lanzará a principios o mediados de octubre.

Intento de baja | Chromestatus Tracker | Error de Chromium

Se movió getContextAttributes() detrás de una marca

La función getContextAttributes() es compatible con CanvasRenderingContext2D desde 2013. Sin embargo, la función no formaba parte de ningún estándar y no se convirtió en parte de uno desde ese momento. Se debería haber implementado detrás de la marca de línea de comandos --enable-experimental-canvas-features, pero no se hizo por error. En Chrome 60, se corrigió este descuido. Se cree que este cambio es seguro, ya que no hay datos que muestren que alguien esté usando el método.

Error de Chromium

Se quitó Headers.prototype.getAll().

La función Headers.prototype.getAll() se quitará según la versión más reciente de la especificación de recuperación.

Intento de eliminación | Chromestatus Tracker | Error de Chromium

Se quitó indexedDB.webkitGetDatabaseNames().

Agregamos esta función cuando la base de datos indexada era relativamente nueva en Chrome y el uso de prefijos estaba en auge. La API muestra de forma asíncrona una lista de nombres de bases de datos existentes en un origen, lo que parecía bastante razonable.

Lamentablemente, el diseño tiene fallas, ya que los resultados pueden quedar obsoletos en cuanto se muestran, por lo que solo se puede usar para el registro, no para una lógica de aplicación seria. El problema de GitHub hace un seguimiento o vincula a una discusión anterior sobre alternativas, lo que requeriría un enfoque diferente. Si bien los desarrolladores han mostrado interés de forma intermitente, debido a la falta de progreso en varios navegadores, los autores de la biblioteca resolvieron el problema.

Los desarrolladores que necesiten esta funcionalidad deben desarrollar su propia solución. Por ejemplo, bibliotecas como Dexie.js usan una tabla global que, a su vez, es otra base de datos para hacer un seguimiento de los nombres de las bases de datos.

Esta función dejó de estar disponible en Chrome 58 y ahora se quitó.

Intento de eliminación | Registro de Chromestatus | Error de Chromium

Se quitaron WEBKIT_KEYFRAMES_RULE y WEBKIT_KEYFRAME_RULE.

Las constantes WEBKIT_KEYFRAMES_RULE y WEBKIT_KEYFRAME_RULE no estándar se quitaron de la regla CSS. En su lugar, los desarrolladores deben usar KEYFRAMES_RULE y KEYFRAME_RULE.

Intento de eliminación | Registro de Chromestatus | Error de Chromium

Interfaz de usuario

Se requiere un gesto del usuario para los diálogos beforeunload

A partir de Chrome 60, el diálogo beforeunload solo aparecerá si el marco que intenta mostrarlo recibió un gesto o una interacción del usuario (o si algún marco incorporado recibió ese gesto). Para que quede claro, esto no es un cambio en el envío del evento beforeunload. Es solo un cambio en si se muestra el diálogo.

El diálogo beforeunload es un cuadro de diálogo modal de la app. Por lo tanto, es inherentemente hostil para el usuario, lo que significa que responde a la navegación del usuario cuestionando su decisión. Esta función tiene usos positivos. Por ejemplo, a menudo se usa para advertir a los usuarios cuando perderán datos si navegan.

Si bien hace tiempo que se quitó la capacidad de que una página proporcione texto para el diálogo beforeunload, los diálogos beforeunload siguen siendo un vector de abuso. En particular, los diálogos beforeunload son un ingrediente de los sitios web de estafas, en los que el audio de reproducción automática y el texto amenazante proporcionan un contexto en el que el mensaje proporcionado por Chromium "¿Estás seguro de que quieres salir de esta página?" se vuelve preocupante.

Queremos encontrar el equilibrio y solo permitir usos adecuados del diálogo beforeunload. Los buenos usos del diálogo son aquellos en los que el usuario tiene un estado que podría perderse. Si el usuario nunca interactuó con la página, no puede tener ningún estado que se pueda perder y, por lo tanto, no corremos el riesgo de perder los datos del usuario si suprimimos el diálogo en ese caso.