Recientemente, anunciamos cambios en el cronograma de baja de Manifest V2 y, si bien mantenemos nuestro compromiso con Manifest V3, reconocemos que hay más trabajo por hacer.
- Antes de anunciar un nuevo cronograma para la baja, terminamos de abordar las brechas en la prioridad de la plataforma y cerramos los errores críticos que se documentaron en esta página.
- Les dimos tiempo a los desarrolladores para compilar, garantizando al menos seis meses entre un anuncio sobre el cronograma y los experimentos pendientes para quitar la compatibilidad con Manifest V2.
Cerramos las brechas en la plataforma
Nos comprometemos a cerrar las siguientes brechas antes de anunciar un nuevo cronograma de baja de Manifest V2:
Los problemas se recopilaron en función de los comentarios de socios, informes de errores y desarrolladores. Seguiremos trabajando para mejorar la estabilidad y el rendimiento general de la plataforma de extensiones.
Actualmente, no hay problemas sin resolver que se consideren una brecha crítica en la plataforma.
Recientemente, se solucionaron los siguientes problemas:
- Compatibilidad con el control de archivos en ChromeOS como reemplazo de
chrome.fileBrowserHandler[Chrome 120]. - Compatibilidad con secuencias de comandos de usuario: Permite el registro de secuencias de comandos de contenido con código arbitrario con la nueva API de userScripts [Chrome 120].
- Keepalives sólidos de service worker adicionales para ciertas operaciones que tardan más de cinco minutos
- Se agregó en Chrome 116 para
permissions.request(),desktopCapture.chooseDesktopMedia(),identity.launchWebAuthFlow()ymanagement.uninstall(). - Se agregó en Chrome 118 para
chrome.debugger.
- Se agregó en Chrome 116 para
- Aumenta la cantidad de conjuntos de reglas estáticos y habilitados para la solicitud neta declarativa (DNR). Los conjuntos de reglas estáticas habilitados aumentaron de 10 a 50, y el total de conjuntos de reglas estáticas aumentó de 50 a 100 [Chrome 120].
- Extiende la funcionalidad del documento fuera de pantalla para admitir más razones por las que usar un documento fuera de pantalla. Se agregó
GEOLOCATIONen Chrome 116. - Mejoramos la compatibilidad con la API de
chrome.tabCapture[Chrome 116]:- Admite las llamadas a
getMediaStreamId()desde un service worker. - Admite la obtención de un
MediaStreamde un ID de transmisión en un documento fuera de pantalla.
- Admite las llamadas a
- Cómo extender la vida útil del service worker mientras haya conexiones
WebSocketactivas [Chrome 116]
Preguntas frecuentes sobre Manifest V3
P.: ¿Planeamos admitir Service Workers persistentes?
R: Una de las razones clave para migrar de las secuencias de comandos en segundo plano a los service workers es el modelo de programación basada en eventos más eficiente en términos de memoria, que proviene de la naturaleza efímera de los service workers. Por lo tanto, no tenemos planificado admitir service workers persistentes. Sin embargo, para abordar las necesidades específicas de los desarrolladores de extensiones, continuamos realizando muchas mejoras en los service workers. En particular, considera lo siguiente:
- Todos los eventos de extensión y las llamadas a la API extenderán la vida útil del service worker.
- Los casos de uso seleccionados, como la mensajería nativa, mantendrán activos los service worker de extensiones por más de 5 min.
P: ¿Hay alguna manera de acceder al DOM en service worker?
R: Seguimos el enfoque que adopta la plataforma web de no incluir el acceso al DOM en los trabajadores web (incluidos los service worker). Para respaldar los casos de uso que requieren acceso al DOM en segundo plano de los service worker, presentamos la posibilidad de delegar trabajo en segundo plano a documentos fuera de pantalla de corta duración, que proporcionan acceso completo al DOM.
P.: ¿Se podrá admitir el código remoto en Manifest V3?
R: Para que las extensiones de Chrome sean más seguras, seguiremos inhabilitando la ejecución de código arbitrario alojado de forma remota en las extensiones de Chrome. Sin embargo, esto no significa que no permitamos todo tipo de ejecución de código dinámico. Aún admitimos diferentes opciones para ejecutar código de forma dinámica en extensiones de Chrome:
- Compatibilidad con
eval()en extensiones de Herramientas para desarrolladores - Compatibilidad con secuencias de comandos de usuario.
- Ejecución de código alojado de forma remota en iframes de la zona de pruebas
- Archivos de configuración alojados de manera remota que se pueden interpretar en el tiempo de ejecución en el paquete de extensión. Sin embargo, las posibles rutas de ejecución deben estar predeterminadas.
P.: Mi extensión de Manifest V2 se basa en webRequestBlocking, que no es compatible con Manifest V3. ¿Cómo puedo seguir proporcionando la misma funcionalidad en Manifest V3?
R.: Estamos seguros de que la mayoría de los casos de uso de bloqueo de solicitudes se pueden resolver con la nueva API de declarativeNetRequest, que tiene el beneficio adicional de evitar la sobrecarga de rendimiento de la comunicación entre procesos, ejecutar código en cada solicitud o requerir un proceso de extensión activo en el momento de la solicitud. Sin embargo, en los casos de uso empresariales (o educativos) complejos, se admite el bloqueo de solicitudes dinámicas.
¿Nos perdimos algo? Comuníquese con nosotros.