No permitir el XMLHTTPRequest() síncrono en el rechazo de páginas
Chrome ahora no permite las llamadas síncronas a XMLHTTPRequest()
durante la página
el descarte cuando el usuario sale de la página o la cierra.
Esto se aplica a beforeunload
, unload
, pagehide
y visibilitychange
.
Para asegurarte de que los datos se envíen al servidor cuando se descargue una página, te recomendamos
sendBeacon()
o Fetch
keep-alive
. Por ahora, los usuarios empresariales pueden usar el
La marca de política AllowSyncXHRInPageDismissal
y los desarrolladores pueden usar el origen
marca de prueba allow-sync-xhr-in-page-dismissal
para permitir solicitudes XHR síncronas
durante la descarga de páginas. Esta es una "inhabilitación" temporal medir y esperamos
quitar esta función experimental en Chrome 88.
Para obtener más detalles sobre esto y las alternativas, consulta Cómo inhabilitar XMLHTTPRequest() síncrono durante el rechazo de páginas.
Intención de quitar | Estado de la plataforma Chrome | Error de Chromium
La compatibilidad con FTP dejó de estar disponible
La implementación actual de FTP en Chrome no es compatible con la encriptación (FTPS) ni proxies. El uso de FTP en el navegador es suficientemente bajo. que ya no es viable invertir para mejorar el cliente de FTP existente. En Además, hay disponibles clientes FTP más capaces en todas las plataformas afectadas.
Chrome 72 quitó la compatibilidad para recuperar subrecursos de documentos a través de FTP y procesamiento de recursos FTP de nivel superior. En este momento, estás navegando a los resultados de las URLs de FTP para mostrar una lista de directorio o una descarga, según el tipo de recurso. Un error en Google Chrome 74 y versiones posteriores provocó que se perdiera la compatibilidad para acceder a los URLs de FTP a través de proxies HTTP. Se eliminó por completo la compatibilidad de proxy con FTP en Google Chrome 76.
El resto de las funciones de la implementación del FTP de Google Chrome están restringidas para mostrar una lista de directorios o descargar un recurso a través de y las conexiones sin encriptar.
El cronograma de baja se establece tentativamente de la siguiente manera:
Chrome 80 (estable en febrero de 2020)
El FTP está inhabilitado de forma predeterminada para clientes no empresariales, pero es posible que esté activado
usando --enable-ftp
o --enable-features=FtpProtocol
de línea de comandos. Como alternativa, se puede activar con el #enable-ftp
.
en chrome://flags.
Chrome 81 (estable en marzo de 2020)
El FTP está inhabilitado de forma predeterminada para todas las instalaciones de Chrome, pero es posible que esté activado.
usando --enable-ftp
o --enable-features=FtpProtocol
de línea de comandos.
Chrome 82 (estable en abril de 2020)
Se quitará por completo la compatibilidad con FTP.
Intención de quitar | Estado de la plataforma Chrome | Error de Chromium
No permitir las ventanas emergentes durante la descarga de páginas
Es posible que las páginas ya no usen window.open()
para abrir una página nueva durante la descarga. El
El bloqueador de ventanas emergentes de Chrome ya prohibió esto, pero ahora sí lo está
o no, el bloqueador de ventanas emergentes está habilitado.
Las empresas pueden usar la marca de política AllowPopupsDuringPageUnload
para permitir
las ventanas emergentes durante la descarga. Chrome espera quitar esta función en Chrome 82.
Intención de quitar | Seguimiento de Chromestatus | Error de Chromium
Se quitó la serialización y transferencia de ImageBitmap no limpia de origen
Ahora se generarán errores cuando una secuencia de comandos intente serializar o transferir ImageBitmap no-origin-clean. Un ImageBitmap no limpio de origen es aquel que contiene datos de imágenes de origen cruzado que la lógica de CORS no verifica.
Intención de quitar | Estado de la plataforma Chrome | Error de Chromium
El manejo de protocolos ahora requiere un contexto seguro
Ahora los métodos registerProtocolHandler()
y unregisterProtocolHandler()
requieren un contexto seguro. Estos métodos son capaces de reconfigurar los estados de los clientes.
de modo que permitirían la transmisión de datos potencialmente sensibles a través de una
en cada red.
El método registerProtocolHandler()
le da a una página web un mecanismo para registrarse
para manejar un protocolo después de que el usuario otorga su consentimiento. Por ejemplo, una cuenta de servicio
de correo electrónico podría registrarse para manejar el esquema mailto:
. El modelo de
El método unregisterProtocolHandler()
permite que un sitio abandone su
registro de control de protocolos.
Intención de quitar | Estado de la plataforma Chrome | Error de Chromium
Se quitó Web Components v0
Se quitó Web Components v0 de Chrome. Las APIs de Web Components v1 son una estándar de la plataforma web que se envió en Chrome, Safari, Firefox y (próximamente) Edge. Para obtener orientación sobre la actualización, consulta Actualización de componentes web: más tiempo para actualizar a las APIs de la versión 1. El las siguientes funciones se han eliminado. Esta baja abarca los elementos que se enumeran a continuación.
Elementos personalizados
Intención de quitar | Estado de la plataforma Chrome | Error de Chromium
Importaciones HTML
Intención de quitar | Estado de la plataforma Chrome | Error de Chromium
Shadow DOM
Intención de quitar | Estado de la plataforma Chrome | Error de Chromium
Se quitó -webkit-app:button para los elementos arbitrarios.
Se cambió -webkit-appearance:button
para que funcione solo con <button>
y <input>
botones. Si se especifica button
para un elemento no compatible, el elemento tiene
el aspecto predeterminado. Todas las demás -webkit-appearance
palabras clave ya tienen
la restricción.
Intención de quitar | Estado de la plataforma Chrome | Error de Chromium
Política de baja
Para mantener la plataforma en buen estado, a veces quitamos APIs de la plataforma web que ejecutaron su curso. Existen muchos motivos por los que podemos quitar un API, como:
- Se reemplazaron por las APIs más nuevas.
- Se actualizan para reflejar los cambios en las especificaciones y, así, alinear y mantener la coherencia con otros navegadores.
- Se trata de experimentos iniciales que nunca tuvieron éxito en otros navegadores y, por lo tanto, pueden aumentar la carga de la compatibilidad para los desarrolladores web.
Algunos de estos cambios afectarán a una cantidad muy pequeña de sitios. Para mitigar los problemas de forma anticipada, intentamos avisarles a los desarrolladores con anticipación para que puedan realizar los cambios necesarios y así mantener sus sitios activos.
Actualmente, Chrome cuenta con un proceso para dar de baja y quitar APIs, que consiste en lo siguiente:
- Anuncia en la lista de distribución blink-dev.
- Configura advertencias y proporciona escalas de tiempo en la consola de Herramientas para desarrolladores de Chrome cuando se detecte el uso en la página.
- Espera, supervisa y quita la función a medida que disminuya el uso.
Puedes encontrar una lista de todas las funciones obsoletas en chromestatus.com con el filtro obsoleto y las funciones quitadas aplicando el filtro Quitado. También trataremos de resumir algunos de los cambios, los motivos y las rutas de migración en estas publicaciones.