Back in July Mozilla’s Dave Camp had talked about in his email how to get Firefox away from being dependent on XBL and XUL. At that time, many on mozillaZine were concerned that this could have dire consequences on the future of Firefox as trying to move away from a development system that has been used for the past decade would not be easy. If anything, it would require a complete rewrite/redesign of the desktop version of Firefox. Many had hoped this would be like a campaign promise and people would forget about it. Unfortunately, Mozilla has lived up their promise on this.
Mozilla announced on Friday in the Mozilla Add-ons Blog they would deprecate support for add-ons using XUL, XPCOM, or XBL (which is what most add-ons are built with now).
Consequently, we have decided to deprecate add-ons that depend on XUL, XPCOM, and XBL. We don’t have a specific timeline for deprecation, but most likely it will take place within 12 to 18 months from now. We are announcing the change now so that developers can prepare and offer feedback.
Mozilla is trying to move add-on developers over to the newer WebExtensions API which is used by Chrome and Opera. This announcement has not gone over well some add-on developers including Christopher Finke who announced on his blog he discontinuing further development of his add-ons as a result of Mozilla’s announcement. Meanwhile Bill McCloskey offers some insights on how add-on developers could make this transition and the possible short comings of Mozilla’s plans.
Another reason Mozilla is pushing towards WebExtensions as they are fully compatible with Electrolysis aka E10s (multi-process). While add-ons which haven’t been upgrade to work with Electrolysis will still run, they are going to be forced to run in the current single process environment which will be slower. Mozilla still hasn’t even determine when Electrolysis would be officially rolled out. The current target is with the Firefox 43 release in mid December 2015. Whatever the release date happens to be, Mozilla plans on killing support for add-ons using XUL, XPCOM, or XBL within 6-months.
Finally, everyone’s favorite add-on topic, Extension Signing was also marketed discussed in this blog post. Mozilla is trying to force tell developers to move towards using WebExtensions as this will make the review process for extension signing simper and quicker:
Starting in Firefox 42, add-on developers will be required to submit extensions for review and signing by Mozilla prior to deployment, and unsigned add-ons cannot be installed or used with Firefox.
We realize that the add-on review process can sometimes be inconvenient for developers. Reviewing is a mostly manual, human process today, and moving an extension from the initial submission to passing a full review that meets our guidelines can be a time-consuming process that can take weeks or months. A major advantage of WebExtensions is that they can be reviewed more quickly. In general, it’s easier to develop a correct WebExtension, and the permissions system makes it easier to recognize malicious add-ons.
I understand that the current XUL, XPCOM, or XBL architecture is over a decade old and their is new and better ways of doing things now. However, the timing of this (along with E10s and extension signing) is horrible. Add-on developers are already unhappy with having to jump through hoops to get their add-ons signed, but are now being told they need to re-write them as well to use WebExtensions to better take advantage of E10s (which has been in the works since around 2009 and Mozilla still doesn’t have a firm date when it will be active) which will make the signing process easier.
Part of the issue is Mozilla has put E10s on hold to allocate resources to other short term projects. E10s should have been fully developed and implemented by now so add-on developers would be able to see the advantage of using WebExtensions. What I can see is happening is add-on developers are going to simply abandon Firefox as Mozilla is becoming increasingly too difficult to work with. Since add-ons are the biggest part of Firefox this could mean the start of the death of the (desktop) Firefox browser. Of course, extension signing will already start the clock ticking next month with Firefox 40 (even though user can still over-ride the forced signing check).
