As a Firefox user you have probably read already that Mozilla plans to introduce major changes to the add-on system of the browser.
The official blog post on the Mozilla blog revealed WebExtensions, Electrolysis, Add-on Signing and the deprecation of XUL, XPCOM and the permissive add-on model in particular, and a rough timeline as well.
To sum it up: Mozilla plans to focus on WebExtensions in the future which offer better compatibility with the extension engines of browsers such as Chrome and Opera.
The deprecation of XUL, XPCOM and the permissive add-on model will break extensions that require deeper permissions or modify core components of the browser.
Mozilla stated that it wants to work with add-on developers, and it apparently is already, to add required functions to WebExtensions to ensure that their extensions will remain compatible with Firefox.
Several add-on developers and Mozillians have blogged about it and expressed their opinion on that development. This article looks at those reactions so that you can get a better picture of what is coming up.
Bill McCloskey (Firefox engineer who works on process separation and garbage collection) responds to concerns that Firefox users and add-on developers have. He states that Mozilla has "lots of ideas" to make popular extensions such as NoScript, Vimperator, Tab Mix Plus or Classic Theme Restorer work using better APIs, and that users and developers can express opinions on https://webextensions.uservoice.com/.
He explains why Mozilla made the announcement.
Again, we’re open to ideas about how to do this. Moving away from XUL will be a long process. We’re announcing all of this early so that we can begin to gather feedback. APIs that are created in a vacuum probably aren’t going to be very useful to people.
Robert O'Callahan, another Mozilla engineer, adds that basing WebExtensions on Chrome's extensions API does not imply limiting WebExtensions to it.
So Firefox addons will continue to be able to do things you can't do in Chrome (though there will be some things you can hack into Firefox's XUL today that won't be supported by WebExtensions, for sure).
Giorgio Maone, creator of the excellent NoScript extension, confirms that Mozilla reached out to him and other add-on authors to design mechanisms and processes that are not yet supported by WebExtensions. This is done to establish a base so that popular extensions such as NoScript and Classic Theme Restorer can be ported to WebExtensions, and to ensure that innovation can still take place.
Developers and users are also concerned about add-ons being prevented from exploring radically new concepts which would require those "super powers" apparently taken away by the WebExtensions API.
I'd like to reassure them: Mozilla is investing a lot of resources to ensure that complex and innovative extensions can prosper also in the new Web-centric ecosystem
Mike Kaply worries that developers won't just "jump at the opportunity" to use the new API, and that the only developers who will actually benefit from this are Chrome developers who will have an easier time porting their extensions to Firefox.
With e10s coming up though, lots of developers have had to make decisions as to whether or not it is worth it to rewrite and some developers have gone through that pain (and it is pain - a lot of pain).
Now developers are being told in the next one to two years they will have to completely rewrite ALL of their add-ons. What are the odds that these hobby add-on developers are going to do that?
Let’s be honest. Availability of APIs isn’t the difficult part of the discussion. Availability of time and energy to even attempt to rewrite all of our add-ons is the problem.
If you have read all posts and comments made in the past couple of days about upcoming changes to Firefox's add-on ecosystem, you may have come to the following conclusion:
If you like our content, and would like to help, please consider making a contribution: