Bajas y eliminaciones de APIs en Chrome 53

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 los cambios en Chrome 52, que está en versión beta a partir del 9 de junio. Esta lista está sujeta a cambios en cualquier momento.

Algoritmos de cifrado basados en DHE que se eliminará gradualmente

Resumen: Los algoritmos de cifrado basados en DHE se quitaron de Chrome 53 para computadoras de escritorio porque no son suficientes para el uso a largo plazo. Los servidores deben usar ECDHE, si está disponible, o un algoritmo de cifrado RSA simple, si no lo está.

Intent to Remove | Chromestatus Tracker | Chromium Bug

El año pasado, Chrome el tamaño mínimo del grupo de TLS Diffie-Hellman de 512 bits a 1,024 bits; sin embargo, 1024 bits no es suficiente a largo plazo. Las métricas informan que alrededor del 95% de las conexiones DHE que ve Chrome usan DHE de 1024 bits. Esto, junto con la forma en que se negocia DHE en TLS, dificulta pasar de 1024 bits.

Si bien existe una especificación en borrador que soluciona este problema, todavía es un borrador y requiere cambios tanto en el cliente como en el servidor. Mientras tanto, el ECDHE ya se implementó y aplicó ampliamente. Los servidores deben actualizarse a ECDHE si está disponible. De lo contrario, asegúrate de habilitar un conjunto de algoritmos de cifrado RSA sin formato.

Los algoritmos de cifrado basados en DHE dejaron de estar disponibles desde Chrome 51. La compatibilidad se quitará de las computadoras de escritorio en Chrome 53.

Advertencia de baja de FileError

Resumen: Se espera que se quite la interfaz obsoleta de FileError en Chrome 54. Reemplaza las referencias a err.code por err.name y err.message.

Intent to Remove | Chromestatus Tracker | Chromium Bug

La versión actual del estándar de la API de File no contiene la interfaz FileError, y su compatibilidad dejó de estar disponible en algún momento de 2013. En Chrome 53, esta advertencia de baja se imprimirá en la consola de Herramientas para desarrolladores:

"FileError" dejó de estar disponible y se quitará en la versión 54. Usa los atributos "name" o "message" del error en lugar de "code".

Esto tiene diferentes efectos en diferentes contextos.

  • FileReader.error y FileWriter.error serán objetos DOMException en lugar de objetos FileError.
  • Para las llamadas FileSystem asíncronas, se pasará FileError.ErrorCode a ErrorCallback en lugar de FileError.
  • Para las llamadas FileSystem síncronas, se arrojará FileError.ErrorCode en lugar de FileError.

Este cambio solo afecta al código que se basa en comparar el código de la instancia de error (e.code) directamente con los valores de enum FileError (FileError.NOT_FOUND_ERR, etcétera). El código que se prueba con constantes codificadas (por ejemplo, e.code === 1) podría fallar si informa errores incorrectos al usuario.

Afortunadamente, los tipos de error FileError, DOMError y DOMException comparten propiedades name y message que proporcionan nombres coherentes para los casos de error (en otras palabras, e.name === "NotFoundError"). En su lugar, el código debe usar esas propiedades, que funcionarán en todos los navegadores y seguirán funcionando una vez que se quite la interfaz FileError.

Se prevé que la eliminación de FileError se realice en Chrome 54.

Se quitó el atributo de resultados para <input type=search>.

Resumen: Se quitará el atributo results porque no forma parte de ningún estándar y se implementa de forma incoherente en los navegadores.

Intent para quitar | Seguimiento de Chromestatus | Error de Chromium

El valor results solo se implementa en webkit y tiene un comportamiento muy incoherente en aquellos que sí lo hacen. Por ejemplo, Chrome agrega un ícono de lupa al cuadro de entrada, mientras que, en el escritorio de Safari, controla cuántas búsquedas anteriores se muestran en una ventana emergente con un clic en el ícono de lupa. Dado que no forma parte de ningún estándar, dejará de estar disponible.

Si aún necesitas incluir el ícono de búsqueda en tu campo de entrada, deberás agregar algunos estilos personalizados al elemento. Para ello, incluye una imagen de fondo y especifica un padding izquierdo en el campo de entrada.

    input[type=search] {
      background: url(some-great-icon.png) no-repeat scroll 15px 15px;
      padding-left:30px;
    }
 ```   

This attribute has been deprecated since Chrome 51.