The next 12 months will change Firefox's add-on landscape fundamentally
A lot is going on at Mozilla, makers of the popular Firefox web browser. In the next 12 months, the organization plans to make fundamental changes to the Firefox web browser which affect core features of the browser including its add-on ecosystem.
As far as add-ons are concerned, there are two changes that will have a direct impact on add-ons, and another looming in the background which may even have a bigger impact than the first two combined.
The first two changes are add-on signing and Electrolysis (e10s), or multi-process Firefox, the change that is looming in the background is the launch of WebExtensions, and the deprecation of classic add-on development features such as XUL or XPCOM.
- Firefox 43: Add-on signing enforcement in all Firefox versions.
- Firefox 44: Add-on signing cannot be disabled anymore in Stable and Beta versions.
- Firefox 46: The projected release version for Firefox Electrolysis (multi-process Firefox).
- Firefox 48: The projected release version for a stable WebExtensions release. It is unclear when classic features are deprecated.
Add-on signing is enforced as of Firefox 43. Warnings were displayed in previous versions of the web browser but no action was taken.
This changed with this month's release of Firefox 43 when the browser started to disable all unsigned add-ons automatically.
Unsigned add-ons are all browser extensions that have not been submitted for signing to Mozilla. This includes dead add-ons, add-ons created by third-parties that are distributed exclusively with their software programs, add-ons created for personal use or Enterprise use, and extensions that have been published only on third-party websites.
While it is possible to remove the add-on signing restriction in Firefox 43, Mozilla plans to remove that option in Firefox 44 for Stable and Beta versions of the web browser.
Extensions that are not signed cannot be installed in Firefox Stable or Beta anymore if Mozilla goes ahead with its plans to remove the switch in those versions of the browser to give users control over the feature.
It is unclear how many extensions cannot be used anymore in Firefox because of the move and how many users are affected by it.
Considering that it includes add-ons hosted on third-party sites, dead add-ons not hosted on Mozilla AMO, custom add-ons, and add-ons distributed with software, it is quite problematic for affected users and businesses.
Firefox Electrolysis (e10s)
The second big change comes in the form of multi-process Firefox. This too impacts add-ons of the browser as many need to be modified to remain compatible with multi-process Firefox.
Mozilla's own Are We e10s Yet website highlights that for instance as it lists compatible, shimmed, broken and untested add-ons. Considering that e10s is only months away -- first tests in Firefox Beta have just started -- it is fair to say that the move will be disruptive as well even if you consider that the list is probably not updated in real-time.
Shimmed in this context means add-ons that are made to work in multi-process Firefox using a compatibility layer. This is only a temporary solution though as it impacts performance.
Multi-process Firefox requires that incompatible add-ons are modified to make them work again. While that may not be a problem for active add-ons, it will have a severe affect on add-ons that are no longer maintained as they will remain incompatible due to that.
WebExtensions / Feature deprecation
Mozilla plans to release a stable version of WebExtensions in Firefox 48 which will be released in mid-2016.
It has not yet announced a Firefox version for the removal of classic add-on development options such as XUL or XPCOM, but mentioned in its original announcement in August 2015 that it will take between 12 to 18 months which could mean as early as Firefox 49 which will be released in August 2016.
The full impact of the deprecation is unknown, but it will impact any add-on for Firefox that makes use of features that Mozilla plans to remove from Firefox.
The organization plans to add at least some of them to WebExtensions, but it requires that add-on developers rewrite their add-ons.
Depending on the API that Mozilla creates, some add-ons may not even be possible under WebExtensions. In addition, dead add-ons and add-ons that are not modified by their respective authors will no longer work once the change goes life.
Are there any solutions that would limit the impact of these changes? There are, to a degree at least.
As far as add-on signing is concerned, solutions could include whitelisting popular trusted add-ons or enforcing the signing of add-ons by Mozilla so that these add-ons can continue to be used.
Mozilla could also pass on removing the preference flag in Firefox Stable and Beta that would allow users to install unsigned add-ons. Considering that Mozilla is all about choice and giving power to its users, it would be the right move in my decision.
As far as Electrolysis is concerned, there is no quick fix available. Mozilla could however integrate the community more in the process by adding a "report incompatibility" button to Firefox's add-on manager.
For WebExtensions, it seems necessary that Mozilla gets lots of user and author feedback to make sure that the API can be used to port popular and even not so popular Firefox extensions without limitations.