Los desarrolladores de Mozilla han actualizado información sobre los planes relacionados con el soporte de las versiones 127 y XNUMX del manifiesto de Chrome en Firefox. Google tiene la intención de dejar de admitir complementos que utilicen la segunda versión del manifiesto en las versiones de prueba de Chrome XNUMX (Dev, Canary y Beta) este junio. En la rama estable, el soporte para la segunda versión del manifiesto no se suspenderá antes de julio.
A su vez, Mozilla no dejará de admitir la segunda versión del manifiesto en el futuro previsible y conservará la capacidad de lanzar complementos que utilicen funciones no disponibles en la tercera versión del manifiesto. La decisión de no hacer que Firefox sea totalmente compatible con la versión 3 del manifiesto de Chrome sigue vigente. Firefox conservará la API webRequest completa, que cambiará al modo de solo lectura en Chrome.
Firefox también utilizará el mecanismo de páginas de eventos para conservar el soporte para ejecutar scripts en segundo plano basados en el DOM, en lugar de lo cual la tercera versión del manifiesto requiere el uso de Service Workers. Los scripts en segundo plano basados en Service Workers aún no son compatibles con Firefox, pero los desarrolladores tendrán la oportunidad de definir tanto un controlador basado en páginas de eventos como scripts basados en Service Workers en el complemento, lo que les permitirá crear complementos. que cumplen con la tercera versión del manifiesto y funcionan en Chrome y Firefox.
El manifiesto de Chrome define las capacidades y recursos disponibles para las extensiones escritas utilizando la API WebExtensions. A partir de la versión 57, Firefox pasó por completo a utilizar la API WebExtensions para desarrollar complementos y dejó de admitir la tecnología XUL. La transición a WebExtensions hizo posible unificar el desarrollo de complementos con las plataformas Chrome, Opera, Safari y Edge, simplificó la transferencia de complementos entre diferentes navegadores web y permitió utilizar completamente el modo multiproceso de operación (los complementos de WebExtensions se pueden ejecutar en procesos separados, aislados del resto del navegador). Para unificar el desarrollo de complementos con otros navegadores, Firefox proporciona compatibilidad casi total con la segunda versión del manifiesto de Chrome.
Como parte de una iniciativa para facilitar la creación de complementos seguros y de alto rendimiento y dificultar la creación de complementos inseguros y lentos, Google ha desarrollado la versión tres del manifiesto. El principal descontento con la tercera versión del manifiesto se debe a la traducción al modo de solo lectura de la API webRequest, que hizo posible conectar sus propios controladores que tienen acceso completo a las solicitudes de red y son capaces de modificar el tráfico sobre la marcha. . En lugar de la API webRequest, la tercera versión del manifiesto agregó la API declarativaNetRequest, que tiene capacidades limitadas y proporciona acceso al motor de filtrado integrado, que procesa de forma independiente las reglas de bloqueo y no permite el uso de sus propios algoritmos de filtrado. .
Entre las características de implementar la tercera versión del manifiesto en Firefox:
- Se agregó una nueva API de filtrado de contenido declarativo, pero a diferencia de Chrome, la compatibilidad con el antiguo modo de bloqueo de la API webRequest no se ha interrumpido.
- Se implementó el mecanismo de páginas de eventos, que es más familiar para los desarrolladores web, no requiere una reelaboración completa de los complementos y elimina las limitaciones asociadas con el uso de Service Workers. Las páginas de eventos permitirán que las adiciones de páginas de fondo existentes cumplan con los requisitos de la tercera versión del manifiesto, manteniendo al mismo tiempo el acceso a todas las capacidades necesarias para trabajar con el DOM.
- El nuevo modelo de solicitud de permiso granular: el complemento no podrá activarse para todas las páginas a la vez (se eliminó el permiso "all_urls"), pero solo funcionará en el contexto de la pestaña activa, es decir. el usuario deberá confirmar que el complemento funciona para cada sitio. En Firefox, todas las solicitudes para acceder a los datos del sitio se considerarán opcionales, y la decisión final sobre conceder el acceso la tomará el usuario, quien podrá decidir de forma selectiva a qué complemento otorgar acceso a sus datos en un sitio en particular.
Para administrar los permisos, se agregó un botón "Extensiones unificadas" a la interfaz para controlar directamente a qué sitios tiene acceso cada extensión; el usuario puede otorgar y revocar el acceso de una extensión a cualquier sitio. La gestión de permisos se aplica solo a los complementos basados en la tercera versión del manifiesto; para los complementos basados en la segunda versión del manifiesto, no se realiza un control de acceso granular a los sitios.
- Cambio en el manejo de solicitudes de origen cruzado: de acuerdo con el nuevo manifiesto, los scripts de procesamiento de contenido estarán sujetos a las mismas restricciones de permiso que para la página principal en la que están incrustados estos scripts (por ejemplo, si la página no tiene acceso al API de ubicación, los complementos del script tampoco recibirán este acceso). Este cambio está completamente implementado en Firefox.
- API basada en promesas. Firefox admite esta API para la tercera versión del manifiesto.
- Evitar la ejecución de código descargado de fuentes externas servidores (Esto se refiere a situaciones en las que un complemento carga y ejecuta código externo). Firefox utiliza el bloqueo de código externo, y los desarrolladores de Mozilla han añadido técnicas adicionales para rastrear las descargas de código. Existe una política de seguridad de contenido (CSP) independiente para los scripts de procesamiento de contenido.
Fuente: opennet.ru
