En casi todas las versiones de Chrome, vemos una cantidad significativa de actualizaciones y mejoras en el producto, su rendimiento y las capacidades de la plataforma web.
En Chrome 50 (fecha estimada de la versión beta: del 10 al 17 de marzo), se realizaron varios cambios en Chrome. Esta lista está sujeta a cambios en cualquier momento.
AppCache dejó de estar disponible en contextos no seguros
Resumen: Para dificultar las secuencias de comandos entre sitios, damos de baja AppCache en orígenes no seguros. Esperamos que, en Chrome 52, solo funcione en los orígenes que entreguen contenido a través de HTTPS.
Intent to Remove | Chromestatus Tracker | Chromium Bug
AppCache es una función que permite el acceso persistente y sin conexión a un origen, que es una elevación de privilegios potente para un ataque de secuencias de comandos entre sitios. Como parte de un esfuerzo más amplio para quitar funciones potentes en orígenes inseguros.
Chrome quita este vector de ataque solo permitiéndolo a través de HTTPS. Daremos de baja la compatibilidad con HTTP en Chrome 50 y esperamos quitarla por completo en Chrome 52.
Se quitó Document.defaultCharset
Resumen: Se quitó document.defaultCharset para mejorar la adecuación a las especificaciones.
Intent to Remove | Chromestatus Tracker | CRBug Issue
document.defaultCharset, que dejó de estar disponible en Chrome 49, es una propiedad de solo lectura que muestra la codificación de caracteres predeterminada del sistema del usuario según su configuración regional. No se considera útil mantener este valor debido a la forma en que los navegadores usan la información de codificación de caracteres en la respuesta HTTP o en la metaetiqueta incorporada en la página.
En su lugar, usa document.characterSet para obtener el primer valor especificado en el encabezado HTTP. Si no está presente, obtendrás el valor especificado en el atributo charset del elemento <meta> (por ejemplo, <meta
charset="utf-8">). Por último, si ninguno de ellos está disponible, document.characterSet será la configuración del sistema del usuario.
Puedes obtener más información sobre el razonamiento para no especificar esto en este problema de GitHub.
Se quitó el atributo Subresource del elemento de vínculo
Resumen: Se quitó la compatibilidad con el valor subresource para el atributo rel de HTMLLinkElement.
Intent to Remove | Chromestatus Tracker | Chromium Bug
El intent del atributo subresource en <link> era cargar previamente un recurso durante el tiempo de inactividad de un navegador. Después de que un navegador descargaba una página, podía descargar previamente recursos, como otras páginas, para que, cuando los usuarios los solicitaran, se pudieran recuperar de la caché del navegador.
El atributo subresource tuvo varios problemas. En primer lugar, nunca funcionó según lo previsto. Los recursos a los que se hace referencia se descargaron con prioridad baja. El atributo nunca se implementó en ningún navegador que no sea Chrome. La implementación de Chrome tenía un error que causaba que los recursos se descargaran dos veces.
Los desarrolladores que buscan mejorar la experiencia del usuario a través de la carga previa de contenido tienen varias opciones, la más personalizable de las cuales es compilar un trabajador de servicio para aprovechar el almacenamiento en caché previo y la API de Caches. Las soluciones adicionales incluyen otros valores para el atributo rel, como preconnect, prefetch, preload y prerender. Algunas de estas opciones son experimentales y pueden no ser ampliamente compatibles.
Quita el resguardo de versiones no seguras de TLS
Resumen: Quita un mecanismo para forzar a los servidores a mostrar datos con versiones de TLS menos seguras o no seguras.
Intent to Remove | Chromestatus Tracker | Chromium Bug
La seguridad de la capa de transporte (TLS) admite un mecanismo para negociar versiones, lo que permite la introducción de nuevas versiones de TLS sin romper la compatibilidad. Algunos servidores implementaron esto de tal manera que los navegadores debían usar extremos no seguros como resguardo. Debido a esto, los atacantes podrían forzar a cualquier sitio web, no solo a los que están configurados de forma incorrecta, a negociar versiones más débiles de TLS.
Los sitios afectados no se conectarán con ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION. Los administradores deben asegurarse de que el software de su servidor esté actualizado. Si el problema persiste, comunícate con el proveedor de software del servidor para ver si hay una solución disponible.
Se quitó KeyboardEvent.prototype.keyLocation
Resumen: Quita un alias innecesario para el atributo Keyboard.prototype.location.
Intent to Remove | Chromestatus Tracker | Chromium Bug
Este atributo es simplemente un alias del atributo Keyboard.prototype.location, que permite desambiguar entre teclas que se encuentran en varios lugares del teclado. Por ejemplo, ambos atributos permiten a los desarrolladores distinguir entre las dos teclas Enter en un teclado extendido.
Controladores de errores y éxitos obligatorios en los métodos RTCPeerConnection
Resumen: Los métodos RTCPeerConnection de WebRTC createOffer() y createAnswer() ahora requieren un controlador de errores y un controlador de éxito. Anteriormente, era posible llamar a estos métodos con solo un controlador de éxito. Ese uso está obsoleto.
Intent to Remove | Chromestatus Tracker | Chromium Bug
En Chrome 49, agregamos una advertencia si llamas a setLocalDescription() o setRemoteDescription() sin proporcionar un controlador de errores. El argumento del controlador de errores es obligatorio a partir de Chrome 50.
Esto forma parte de despejar el camino para presentar promesas en estos métodos, como lo requiere la especificación de WebRTC.
A continuación, se muestra un ejemplo de la demo de RTCPeerConnection de WebRTC (main.js, línea 126):
function onCreateOfferSuccess(desc) {
pc1.setLocalDescription(desc, function() {
onSetLocalSuccess(pc1);
}, onSetSessionDescriptionError);
pc2.setRemoteDescription(desc, function() {
onSetRemoteSuccess(pc2);
}, onSetSessionDescriptionError);
pc2.createAnswer(onCreateAnswerSuccess, onCreateSessionDescriptionError);
}
Ten en cuenta que tanto setLocalDescription() como setRemoteDescription() tienen un
controlador de errores. Los navegadores más antiguos que esperan solo un controlador de éxito simplemente ignoran el argumento del controlador de errores si está presente. Llamar a este código en un navegador anterior no causará una excepción.
En general, para las aplicaciones WebRTC de producción, te recomendamos que uses adapter.js, un shim que mantiene el proyecto WebRTC para proteger las apps de los cambios de especificación y las diferencias de prefijos.
Ya no se admite XMLHttpRequestProgressEvent.
Resumen: Se quitará la interfaz XMLHttpRequestProgressEvent, junto con los atributos position y totalSize.
Intent to Remove | Chromestatus Tracker | Chromium Bug
Este evento existía para admitir las propiedades de compatibilidad de Gecko position y totalSize. La compatibilidad con los tres se eliminó en Mozilla 22, y la funcionalidad hace mucho que se reemplazó por ProgressEvent.
var progressBar = document.getElementById("p"),
client = new XMLHttpRequest()
client.open("GET", "magical-unicorns")
client.onprogress = function(pe) {
if(pe.lengthComputable) {
progressBar.max = pe.total
progressBar.value = pe.loaded
}
}
Quita las extensiones de contenido multimedia encriptado con prefijos
Resumen: Se quitaron las extensiones de contenido multimedia encriptadas con prefijo para dar lugar a un reemplazo sin prefijo basado en especificaciones.
Intent to Remove | Chromestatus Tracker | Chromium Bug
En Chrome 42, lanzamos una versión basada en especificaciones y sin prefijo de extensiones de contenido multimedia encriptado. Esta API se usa para descubrir,
seleccionar e interactuar con sistemas de administración de derechos digitales para usarlos con
HTMLMediaElement.
Eso fue hace casi un año. Y, como la versión sin prefijo tiene más capacidades que la versión con prefijo, es hora de quitar la versión con prefijo de la API.
Se quitó la compatibilidad con las propiedades SVGElement.offset
Resumen: Se quitaron las propiedades de desplazamiento para SVGElement en favor de las propiedades más compatibles en HTMLElement.
Intent to Remove | Chromestatus Tracker | Chromium Bug
Las propiedades de offset son compatibles con HTMLElement y SVGElement desde hace mucho tiempo. Sin embargo, Gecko y Edge solo las admiten en HTMLElement. Para mejorar la coherencia entre los navegadores, estas propiedades dejaron de estar disponibles en Chrome 48 y ahora se quitarán.
Aunque las propiedades equivalentes forman parte de HTMLElement, los desarrolladores que buscan una alternativa también pueden usar getBoundingClientRect().