Firefox will get a new extensions API, without backward compatibility

Mozilla developers have announced that in Firefox 45, a new implementation of the API for browser extensions will be added. It is called WebExtensions and uses native HTML technology. WebExtensions will make it possible to create extensions compatible with Google Chrome and vice versa.


firefox logo banner
The first alpha release of the WebExtensions API which we will see in Firefox 45, is expected in March 2016. In a blog post, Mozilla mentioned that the following APIs are expected to be implemented by that time: alarms, contextMenus, pageAction and browserAction. Plus there will be a bunch of partially supported APIs: bookmarks, cookies, extension, i18n, notifications, runtime, storage, tabs, webNavigation, webRequest, windows.

Support for these new type of addons is already implemented in the repository. It will be rolled out to the public along with Firefox 44. By Firefox 47, the implementation of WebExtensions is expected to be in the beta stage. Finally, in Firefox 48, WebExtensions will reach a usable stage.

After that, support for classic (XUL-based) add-ons will be dropped after some time! It is not clear for how long the support for classic add-ons will remain available in Firefox.

Add-ons created with WebExtensions will be compatible with Electrolysis/multi-process option of the Firefox browser. When enabled, it runs add-ons in a separate process, which isolates add-ons from the main browser process. Tabs will work the same way - an isolated process per opened tab will be provided by the multi-process option.

The classic add-ons have issues with Electrolysis. Many of them may stop working completely when Electrolysis is rolled out in the stable Firefox release, which is expected in April 2016 with Firefox 46.

While WebExtensions add-ons can be used in other browsers like Opera or Chrome, the potential loss of many useful Firefox extensions is so disappointing that many users are likely to stop using Firefox. These changes, along with the signature enforcement for extensions, which cannot be turned off starting with Firefox 44 can significantly reduce the flexibility and the power of Firefox. It is quite possible that many things possible today through add-ons in Firefox will not be available using the new WebExtensions APIs. For example, I am skeptical on whether my favorite Tab Mix Plux XUL-based add-on can be possible with the new extensions model. Once XUL-based add-on support is dropped, it may not be possible to create such an add-on.

While it is understandable that Mozilla's goal is to improve Firefox, make it safer, faster and more friendly for the average user, many users including myself won't be happy if the price we have to pay for such changes cripples the functionality of the browser. What is your opinion about all these future changes? Do you find them worth it?

Support us

Winaero greatly relies on your support. You can help the site keep bringing you interesting and useful content and software by using these options:

If you like this article, please share it using the buttons below. It won't take a lot from you, but it will help us grow. Thanks for your support!


Author: Sergey Tkachenko

Sergey Tkachenko is a software developer who started Winaero back in 2011. On this blog, Sergey is writing about everything connected to Microsoft, Windows and popular software. Follow him on Telegram, Twitter, and YouTube.

17 thoughts on “Firefox will get a new extensions API, without backward compatibility”

  1. Seems like every browser is becoming Chrome clone. Everything is being done to fight the market share rather than focus on the loyal core base of users. When you try to reach mass market you have to dumb it down. Shame.

      1. I heard Palemoon will become a complete fork, with the forked rendering engine. Quite possible the developers behind it will fork the UI/API as well.

        1. Hi Sergey, do you have more information about this? I have Vivaldi for the next ship, but if this is true I might use Pale Moon instead.

  2. The ONLY reason I use firefox is a single addon, Firegestures. It simply works, every time, on every page, without problems.

    There are no equivalent mouse gesture addons for Chrome, even after all these years. Every, and I do mean EVERY, mouse gesture addon for Chrome sucks rocks and is more than likely malware to boot. I’ve tried all of them. For whatever reason, it is simply impossible to create a mouse gesture addon for Chrome that truly, flawlessly, works.

  3. I’ve been using Opera (the real one) for years and when it decided to cancel years of development to become a Chrome clone, I had to use Firefox, even if I don’t love it too much. When also Firefox will become a Chrome clone, my only choice will be Palemoon (a fork of Firefox that won’t follow its changing).

    1. Note that even though Opera /invented/ mouse gestures, the new chromium-based Opera does not have configurable mouse gestures, so it’s not an option for me either.

  4. I’ll certainly stay with my favourite one : Cyberfox. And I’m sure the developers will also (as for many other annoyances up to now) propose a nice solution (workaround) for this one … :-)

Leave a Reply

Your email address will not be published.

Using Telegram? Subscribe to the blog channel!
Hello. Add your message here.