{"id":114309,"date":"2024-03-14T12:25:45","date_gmt":"2024-03-14T10:25:46","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/plany-v-otnoshenii-podderzhki-v-firefox-vtoroj-i-tretej-versij-manifesta-chrome"},"modified":"2024-03-14T12:25:45","modified_gmt":"2024-03-14T10:25:46","slug":"plany-v-otnoshenii-podderzhki-v-firefox-vtoroj-i-tretej-versij-manifesta-chrome","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/plany-v-otnoshenii-podderzhki-v-firefox-vtoroj-i-tretej-versij-manifesta-chrome","title":{"rendered":"Plans for supporting versions two and three of the Chrome manifest in Firefox.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Developers from Mozilla have updated information about their plans concerning support for the second and third versions of the Chrome manifest in Firefox. Google intends to discontinue support for extensions using the second version of the manifest in the test releases of Chrome 127 (Dev, Canary, and Beta) this June. In the stable branch, support for the second version of the manifest will not end before July. <\/p>\n
In turn, Mozilla will not discontinue support for the second version of the manifest in the foreseeable future and will maintain compatibility for running extensions that utilize capabilities unavailable in the third version of the manifest. The decision to not ensure full compatibility with the third version of the Chrome manifest in Firefox remains in effect. A full webRequest API will continue to exist in Firefox, which in Chrome will be transitioned to read-only mode. <\/p>\n
In Firefox, support for background scripts based on DOM will also be preserved using the Event Pages mechanism, instead of which the third version of the manifest requires the use of Service Workers. Background scripts based on Service Workers are not currently supported in Firefox, but developers will be allowed to define both Event Pages-based handlers and Service Worker-based scripts in their extensions, enabling the creation of extensions that comply with the third version of the manifest and work in both Chrome and Firefox. <\/p>\n
The Chrome manifest defines the capabilities and resources available for extensions written using the WebExtensions API. Starting from version 57, Firefox fully transitioned to using the WebExtensions API for extension development and discontinued support for XUL technology. The switch to WebExtensions allowed for the unification of extension development with Chrome, Opera, Safari, and Edge platforms, simplified the porting of extensions between different web browsers, and enabled the full use of multi-process mode (WebExtensions can run in separate processes, isolated from other parts of the browser). To unify extension development with other browsers, Firefox ensures almost complete compatibility with the second version of the Chrome manifest. <\/p>\n
As part of the initiative to simplify the creation of safe and high-performance extensions while complicating the possibility of creating unsafe and slow extensions, Google developed the third version of the manifest. The main dissatisfaction with the third version of the manifest stems from the transition of the webRequest API to read-only mode, which allowed the connection of custom handlers that had full access to network requests and could modify traffic on the fly. Instead of the webRequest API, the third version of the manifest introduces a limited capability declarativeNetRequest API, which provides access to a built-in filtering engine that independently processes blocking rules and does not allow the use of custom filtering algorithms. <\/p>\n
Among the features of the implementation of the third version of the manifest in Firefox: <\/p>\n
\n
A new declarative content filtering API has been added, but unlike Chrome, support for the old blocking mode of the webRequest API has not been discontinued. <\/li>\n
The Event Pages mechanism has been implemented, which is more familiar to web developers, does not require a complete overhaul of extensions, and removes limitations associated with the use of Service Workers. Event Pages will allow existing extensions with background pages to meet the requirements of the third manifest version while maintaining access to all the necessary capabilities for working with the DOM.\n
The new granular permissions request model \u2014 the extension cannot be activated immediately for all pages (the 'all_urls' permission has been removed), and it will work only in the context of the active tab, meaning the user will need to confirm the extension's functionality for each site. In Firefox, all requests for access to site data will be considered optional, and the final decision to grant access will be made by the user, who can selectively decide which extension can access their data on a given site.\n
A «Unified Extensions» button has been added to the interface for managing permissions, allowing users to directly control which websites each extension has access to\u2014users can grant or revoke an extension's access to any website. Permission management applies only to extensions based on the third version of the manifest; granular access control for websites is not available for extensions on the second version of the manifest. <\/p>\n
<\/center> <\/li>\n
Change in handling Cross-origin requests \u2014 according to the new manifest, the same permission restrictions that apply to the main page will also apply to the content script that is injected into it (for example, if the page does not have access to the location API, then the extension's script will also not gain that access). This change is fully implemented in Firefox. <\/li>\n
Promise-based API. Firefox supports this API for the third manifest version. <\/li>\n
![\"Plans](\"\/wp-content\/uploads\/2024\/03\/fe76b83a5dc61990f0346c1d84f29114.png\")
<\/center> <\/li>\n