Bajas y eliminaciones de APIs en Chrome 53

Joe Medley
Jo Medley

En casi todas las versiones de Chrome, vemos una cantidad significativa de actualizaciones y mejoras del producto, su rendimiento y 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 en Chrome 53 para computadoras de escritorio porque no son suficientes para un uso a largo plazo. Los servidores deben utilizar ECDHE, si está disponible, o un algoritmo de cifrado RSA sin formato, si no lo está.

Intent de quitar | Seguimiento de Chromestatus | Error de Chromium

El año pasado, Chrome implementó el tamaño mínimo del grupo TLS Diffie-Hellman 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 usa DHE de 1024 bits. Esto, sumado a la forma en que se negocia DHE en TLS, dificulta el paso de 1024 bits.

Aunque hay una especificación de borrador que corrige este problema, sigue siendo un borrador y requiere cambios tanto en el cliente como en el servidor. Por otro lado, ECDHE ya está ampliamente implementado. Los servidores deben actualizarse a ECDHE si están disponibles. De lo contrario, asegúrate de que esté habilitado un conjunto de algoritmos de cifrado de RSA sin formato.

Los algoritmos de cifrado basados en DHE dejaron de estar disponibles desde Chrome 51. Se quitará la compatibilidad del escritorio en Chrome 53.

Advertencia de baja de FileError

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

Intent de quitar | Seguimiento de Chromestatus | Error de Chromium

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, se mostrará esta advertencia de baja en la consola de Herramientas para desarrolladores:

"FileError" dejó de estar disponible y se quitará en la versión 54. Utiliza los atributos 'nombre' o 'mensaje' del error en lugar de 'código'.

Esto tiene distintos efectos en distintos contextos.

  • FileReader.error y FileWriter.error serán objetos DOMException en lugar de FileError.
  • Para las llamadas asíncronas de FileSystem, ErrorCallback se pasará FileError.ErrorCode en lugar de FileError.
  • Para las llamadas síncronas, se arrojará FileSystem 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 enumeración FileError (FileError.NOT_FOUND_ERR, etcétera). El código que prueba las constantes hard-coded (por ejemplo, e.code === 1) podría informar errores incorrectos al usuario.

Afortunadamente, los tipos de error FileError, DOMError y DOMException comparten propiedades name y message que dan 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é la eliminación de FileError en Chrome 54.

Quitar el atributo de resultados de <input type=search>

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

Intent de quitar | Seguimiento de Chromestatus | Error de Chromium

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

Si aún debes incluir el ícono de búsqueda en el campo de entrada, tendrás que agregar un estilo personalizado al elemento. Puedes hacerlo incluyendo una imagen de fondo y especificando 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.