The organization plans to release a stable WebExtensions API with Firefox 48 while developers can submit add-ons to Mozilla’s Add-ons library already and provide feedback on existing add-ons and capabilities they require to function.
Mozilla’s main goal with the introduction of WebExtensions is to unify Firefox’s extensions API and architecture with that of Chromium and browsers based on Chromium such as Google Chrome and Opera.
Support for Chromium’s extension architecture is the first step of the process as it makes it easier to port Chrome extensions to Firefox (and Firefox extensions created with WebExtensions to Chrome).
Developers benefit from the approach as it requires minimal effort to port extensions to another web browser.
Mozilla is aware however that Firefox’s current add-on architecture is more powerful than the WebExtensions baseline, and that many of the add-ons available for the browser cannot be ported using the WebExtensions API if it is not extended to improve its capabilities.
Considering that Mozilla plans to deprecate XUL and XPCOM in the future, it would result in add-ons becoming incompatible with Firefox at that point unless they are ported by their authors or people who take over to WebExtensions or the Add-on SDK.
That’s however only possible of WebExtensions or the Add-on SDK provide the functionality needed, and while Mozilla wants to ensure that for select add-ons like NoScript or Mega, it is possible that others will fall through the cracks if functions that they rely on are not made available.
Mozilla notes that WebExtensions offer advantages over traditional add-ons for the browser. First, the API is created from the ground up to support Firefox’s upcoming multi-process architecture.
Second, WebExtensions add-ons are more secure than legacy add-ons resulting in improved security and stability, and faster review times.
If you look at the bigger picture, you will notice additional upcoming issues in regards to the introduction of WebExtensions and multi-process Firefox, and the deprecation of XUL and XPCOM.
While you could analyze each change on its own, it makes sense from a user’s perspective to look at the changes as a whole as they all affect the add-on landscape of the browser.
The WebExtensions API on its own is not a bad thing but beneficial to the Firefox community. Add the deprecation of XUL and XPCOM, and multi-process Firefox to it, and it all comes down to how powerful the capabilities of the WebExtensions API will be.
Adding the necessary functions to WebExtensions is however only one part of the process. Developers need to port their existing add-ons to the new API if their extensions become incompatible when XUL or XPCOM are deprecated in Firefox.
Firefox users who are interested in the process Mozilla makes in regards to WebExtensions can check out the main tracking bug for the first version of WebExtensions on Bugzilla.
Now You: What are your expectations in regards to WebExtensions?