{"id":105614,"date":"2022-11-18T03:36:41","date_gmt":"2022-11-18T01:36:42","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/mozilla-nachnyot-prinimat-dopolneniya-na-baze-tretej-versii-manifesta-chrome"},"modified":"2022-11-18T03:36:41","modified_gmt":"2022-11-18T01:36:42","slug":"mozilla-nachnyot-prinimat-dopolneniya-na-baze-tretej-versii-manifesta-chrome","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/news\/mozilla-nachnyot-prinimat-dopolneniya-na-baze-tretej-versii-manifesta-chrome","title":{"rendered":"Mozilla commencera \u00e0 accepter les extensions bas\u00e9es sur la troisi\u00e8me version du manifeste Chrome","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Le 21 novembre, le catalogue AMO (addons.mozilla.org) commencera \u00e0 accepter et \u00e0 signer num\u00e9riquement les extensions utilisant la troisi\u00e8me version du manifeste Chrome. Ces extensions pourront \u00eatre test\u00e9es dans les versions nocturnes de Firefox. Dans les versions stables, le support de la troisi\u00e8me version du manifeste sera int\u00e9gr\u00e9 dans Firefox 109, pr\u00e9vu pour le 17 janvier 2023. Le support de la deuxi\u00e8me version du manifeste sera maintenu dans un avenir proche, mais \u00e0 la fin de l'ann\u00e9e 2023, apr\u00e8s \u00e9valuation de la dynamique de migration des extensions vers la troisi\u00e8me version, la possibilit\u00e9 de r\u00e9trogradage du support de la deuxi\u00e8me version vers une cat\u00e9gorie obsol\u00e8te sera envisag\u00e9e. <\/p>\n
Le manifeste Chrome d\u00e9finit les fonctionnalit\u00e9s et les ressources accessibles aux extensions \u00e9crites en utilisant l'API WebExtensions. \u00c0 partir de la version 57, Firefox a compl\u00e8tement migr\u00e9 vers l'utilisation de l'API WebExtensions pour le d\u00e9veloppement d'extensions et a arr\u00eat\u00e9 de soutenir la technologie XUL. Le passage aux WebExtensions a permis d'uniformiser le d\u00e9veloppement des extensions avec celles des plateformes Chrome, Opera, Safari et Edge, simplifiant le portage des extensions entre diff\u00e9rents navigateurs web et permettant une utilisation compl\u00e8te du mode multiprocessus (les extensions WebExtensions peuvent s'ex\u00e9cuter dans des processus s\u00e9par\u00e9s, isol\u00e9s des autres parties du navigateur). Pour uniformiser le d\u00e9veloppement des extensions avec les autres navigateurs, Firefox assure une compatibilit\u00e9 presque totale avec la deuxi\u00e8me version du manifeste Chrome. <\/p>\n
Actuellement, Chrome travaille sur la migration vers la troisi\u00e8me version du manifeste, tandis que le support de la deuxi\u00e8me version sera arr\u00eat\u00e9 en janvier 2024. L'objectif principal des modifications apport\u00e9es dans cette nouvelle version est de simplifier la cr\u00e9ation d'extensions s\u00e9curis\u00e9es et performantes, tout en compliquant la possibilit\u00e9 de cr\u00e9er des extensions non s\u00e9curis\u00e9es et lentement r\u00e9actives. \u00c9tant donn\u00e9 que la troisi\u00e8me version du manifeste a fait l'objet de critiques et entra\u00eenera des dysfonctionnements pour de nombreuses extensions de blocage de contenu ind\u00e9sirable et de s\u00e9curit\u00e9, Mozilla a d\u00e9cid\u00e9 de s'\u00e9loigner de l'objectif de compatibilit\u00e9 compl\u00e8te avec le manifeste dans Firefox et de mettre en \u0153uvre certaines modifications d'une mani\u00e8re diff\u00e9rente. <\/p>\n
Le principal m\u00e9contentement concernant la troisi\u00e8me version du manifeste est li\u00e9 au passage en mode lecture seule de l'API webRequest, qui permettait de connecter des gestionnaires personnalis\u00e9s ayant un acc\u00e8s complet aux requ\u00eates r\u00e9seau et capables de modifier le trafic \u00e0 la vol\u00e9e. Cette API est utilis\u00e9e dans uBlock Origin et de nombreuses autres extensions pour bloquer le contenu ind\u00e9sirable et garantir la s\u00e9curit\u00e9. Au lieu de l'API webRequest, la troisi\u00e8me version du manifeste propose une API declarativeNetRequest, limit\u00e9e dans ses capacit\u00e9s, qui donne acc\u00e8s \u00e0 un moteur int\u00e9gr\u00e9 pour le filtrage, g\u00e9rant lui-m\u00eame les r\u00e8gles de blocage sans permettre l'utilisation d'algorithmes de filtrage personnalis\u00e9s ni la d\u00e9finition de r\u00e8gles complexes se chevauchant en fonction des conditions. <\/p>\n
Parmi les caract\u00e9ristiques de la mise en \u0153uvre du nouveau manifeste dans Firefox : <\/p>\n
\n
Un nouvel API d\u00e9claratif de filtrage de contenu a \u00e9t\u00e9 ajout\u00e9, mais contrairement \u00e0 Chrome, le support de l'ancien mode de blocage de l'API webRequest n'a pas \u00e9t\u00e9 supprim\u00e9.\n
Le manifeste d\u00e9finit le remplacement des pages d'arri\u00e8re-plan par une variante des Service Workers, fonctionnant comme des processus d'arri\u00e8re-plan (Background Service Workers). Pour garantir la compatibilit\u00e9 future, Firefox mettra en \u0153uvre le support des Service Workers, mais pour l'instant, un nouveau m\u00e9canisme appel\u00e9 Event Pages est propos\u00e9, qui est plus familier pour les d\u00e9veloppeurs web, ne n\u00e9cessitant pas une refonte compl\u00e8te des extensions et \u00e9liminant les limitations li\u00e9es \u00e0 l'utilisation des Service Workers. Les Event Pages permettront d'adapter les extensions existantes avec des pages d'arri\u00e8re-plan aux exigences de la troisi\u00e8me version du manifeste tout en conservant l'acc\u00e8s \u00e0 toutes les fonctionnalit\u00e9s n\u00e9cessaires pour travailler avec le DOM. <\/li>\n
Le nouveau mod\u00e8le granulaire de demande de permissions \u2014 l'extension ne pourra pas s'activer imm\u00e9diatement pour toutes les pages (la permission \u00ab all_urls \u00bb a \u00e9t\u00e9 supprim\u00e9e), mais fonctionnera uniquement dans le contexte de l'onglet actif, c'est-\u00e0-dire que l'utilisateur devra confirmer l'utilisation de l'extension pour chaque site. Dans Firefox, toutes les requ\u00eates d'acc\u00e8s aux donn\u00e9es du site seront consid\u00e9r\u00e9es comme optionnelles, et la d\u00e9cision finale concernant l'octroi de l'acc\u00e8s sera prise par l'utilisateur, qui pourra d\u00e9cider s\u00e9lectivement quelle extension pourra acc\u00e9der \u00e0 ses donn\u00e9es sur tel ou tel site.\n
Une nouveau bouton «Unified Extensions» a \u00e9t\u00e9 ajout\u00e9 \u00e0 l'interface pour g\u00e9rer les permissions, qui peut d\u00e9j\u00e0 \u00eatre test\u00e9e dans les builds nocturnes de Firefox. Ce bouton offre des moyens de g\u00e9rer directement l'acc\u00e8s de chaque extension \u00e0 des sites web \u2014 l'utilisateur peut accorder ou r\u00e9voquer l'acc\u00e8s d'une extension \u00e0 n'importe quel site. La gestion des permissions ne s'applique qu'aux extensions bas\u00e9es sur la version trois du manifeste, car la gestion granulaire des droits d'acc\u00e8s des sites n'est pas r\u00e9alis\u00e9e pour les extensions bas\u00e9es sur la version deux.
<\/center> <\/li>\n
Changement dans le traitement des requ\u00eates Cross-origin \u2014 conform\u00e9ment au nouveau manifeste, les m\u00eames restrictions de permissions s'appliqueront aux scripts de traitement de contenu que pour la page principale dans laquelle ces scripts sont int\u00e9gr\u00e9s (par exemple, si la page n'a pas acc\u00e8s \u00e0 l'API de g\u00e9olocalisation, le script de l'extension n'aura \u00e9galement pas cet acc\u00e8s). Ce changement est enti\u00e8rement impl\u00e9ment\u00e9 dans Firefox. <\/li>\n
API bas\u00e9e sur les Promesses. Firefox prend en charge cette API et la transf\u00e9rera dans l'espace de noms «chrome.*» pour la troisi\u00e8me version du manifeste. <\/li>\n
![\"Mozilla](\"\/wp-content\/uploads\/2022\/11\/62422c3bf8021866caee67b47e642d5c.jpg\")
<\/center> <\/li>\n