{"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\/en\/blog\/news\/mozilla-nachnyot-prinimat-dopolneniya-na-baze-tretej-versii-manifesta-chrome","title":{"rendered":"Mozilla will begin accepting extensions based on the third version of the Chrome manifest","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
On November 21, the AMO catalog (addons.mozilla.org) will start accepting and verifying extensions using the third version of the Chrome manifest with a digital signature. These extensions can be tested in the nightly builds of Firefox. The stable releases will include support for the third version of the manifest in Firefox 109, scheduled for January 17, 2023. Support for the second version of the manifest will remain in the foreseeable future, but by the end of 2023, after evaluating the dynamics of the transition to the third version, the possibility of marking support for the second version as deprecated will be considered. <\/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
Currently, Chrome is working on the transition to the third version of the manifest, and support for the second version will end in January 2024. The main goal of the changes made in the new version is to simplify the creation of safe and high-performance extensions while complicating the possibility of creating unsafe and slow extensions. Since the third version of the manifest has faced criticism and will break many extensions for blocking unwanted content and ensuring security, Mozilla has decided to step back from full compatibility with the manifest in Firefox and 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
Among the features of the new manifest implementation 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.\n
The manifest defines a replacement for background pages with Service Workers, which operate as background processes (Background Service Workers). To ensure future compatibility, Firefox will implement support for Service Workers, but for now, a new mechanism called Event Pages is proposed, which is more familiar to web developers, requires no complete overhaul of extensions, and eliminates the limitations associated with using Service Workers. Event Pages will allow existing extensions with background pages to conform to the requirements of the third version of the manifest while maintaining access to all necessary functionalities for working with the DOM. <\/li>\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 new 'Unified Extensions' button has been added to the permissions management interface, which can already be tested in the nightly builds of Firefox. The button provides tools for directly managing which sites each extension has access to \u2014 users can grant and revoke access for any extension to any site. Permissions management applies only to extensions based on the third version of the manifest; for extensions based on the second version of the manifest, granular access control for sites is not implemented.
<\/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 and will transfer it to the 'chrome.*' namespace for the third version of the manifest. <\/li>\n
![\"Mozilla](\"\/wp-content\/uploads\/2022\/11\/62422c3bf8021866caee67b47e642d5c.jpg\")
<\/center> <\/li>\n