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.

Eliminación gradual de los algoritmos de cifrado basados en DHE

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, cambiamos el tamaño mínimo del grupo Diffie-Hellman de TLS de 512 bits a 1024 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 hay un borrador de especificación que corrige este problema, sigue siendo un borrador y requiere cambios en el cliente y 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. Se reemplazaron 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 DevTools:

"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.

Por fortuna, los tipos de errores FileError, DOMError y DOMException comparten las 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 to Remove | Chromestatus Tracker | Chromium Bug

El valor results solo se implementa en webkit y se comporta de manera muy incoherente en los que sí lo hacen. Por ejemplo, Chrome agrega un ícono de lupa al cuadro de entrada, mientras que en Safari para computadoras de escritorio, controla cuántas búsquedas anteriores se muestran en una ventana emergente que se muestra haciendo 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.