{"id":104092,"date":"2022-05-19T21:36:47","date_gmt":"2022-05-19T19:36:47","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/v-firefox-nachalos-testirovanie-tretej-versii-manifesta-chrome"},"modified":"2022-05-19T21:36:47","modified_gmt":"2022-05-19T19:36:47","slug":"v-firefox-nachalos-testirovanie-tretej-versii-manifesta-chrome","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/v-firefox-nachalos-testirovanie-tretej-versii-manifesta-chrome","title":{"rendered":"Testing of the third version of the Chrome manifest has begun in Firefox.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Mozilla has announced the start of testing for the implementation of the third version of the Chrome manifest in Firefox, which defines the capabilities and resources available for extensions written using the WebExtensions API. To test the third version of the manifest in the Firefox 101 beta, set the parameter 'extensions.manifestV3.enabled' to true and the parameter 'xpinstall.signatures.required' to false in the about:config page. The about:debugging interface can be used to install extensions. Enabling the third version of the manifest by default is scheduled for the end of the year. <\/p>\n
Starting from version 57, Firefox fully switched to using the WebExtensions API for extension development and discontinued support for the XUL technology. The transition to WebExtensions has allowed for the unification of extension development with Chrome, Opera, Safari, and Edge, simplified the porting of extensions between different web browsers, and enabled full use of the multiprocess mode (WebExtensions can run in separate processes, isolated from other parts of the browser). To unify extension development with other browsers, Firefox offers almost complete compatibility with the second version of the Chrome manifest. <\/p>\n
Currently, Chrome is working on transitioning to the third version of the manifest, and support for the second version will be discontinued in January 2023. Since the third version of the manifest has been criticized and will lead to the malfunctioning of many extensions for blocking unwanted content and ensuring security, Mozilla has decided to move away from the practice of ensuring full compatibility with the manifest in Firefox and to implement some changes differently. <\/p>\n
The main complaint about the third version of the manifest is related to the transition of the webRequest API to a read-only mode, which previously allowed the integration of custom handlers with full access to network requests and the ability to modify traffic on the fly. This API is used in uBlock Origin and many other extensions for blocking unwanted content and ensuring security. Instead of the webRequest API, the third version of the manifest introduces the limited declarativeNetRequest API, which provides access to a built-in filtering engine that processes blocking rules independently and does not allow the use of custom filtering algorithms or the definition of complex overlapping rules based on conditions. <\/p>\n
In the proposed implementation of the third version of the manifest in Firefox, 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. Among other features of the new manifest implementation in Firefox: <\/p>\n
\n
The manifest defines the replacement of background pages with a Service Workers option that operates as background processes (Background Service Workers). For compatibility, this requirement will be implemented in Firefox, but a new Event Pages mechanism has also been proposed, which is more familiar to web developers, does not require a complete overhaul of add-ons, and eliminates limitations related to the use of Service Workers. Event Pages will allow existing add-ons with background pages to conform to the third version of the manifest while maintaining access to all necessary DOM functionalities. Currently, only Event Pages are supported in the test implementation of the manifest in Firefox, and support for the Service Workers-based solution is promised to be added later. This proposal has been supported by Apple, which has implemented Event Pages in Safari Technology Preview 136.\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
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 already supports this API and will transition it to the 'chrome.*' namespace for the third version of the manifest. <\/li>\n