WebExtensions/FAQ

It sounds like you're copying Google....

The Chrome extension API was designed to work well with process separation and we are certainly taking inspiration from it and copying functionality where it makes sense. In other areas it doesn't.

How will the WebExtensions API be different from the Chrome Extension API

You could imagine a Venn Diagram of the two extension APIs. One circle is Chrome's, the other WebExtensions. The overlapping are are basic extension functionality (give some examples).

Outside of that overlap area would be the areas of differentiation. For example, we don't have much interest in providing easy access to Google's services though WebExtensions. We do however want to support certain use cases that don't seem to be a priority for Google. We have identified a few such areas that we want to support such as ad-blocking, tab management, UI modification and time/location shifting content.

Why WebExtensions and not Jetpack?

There are several reasons why we chose to start with Chrome's API. First, there are more extensions already written for it and more developers familiar with it. Second, it has built-in support for content blocking, which Jetpack lacks. These content blocking APIs are used by a lot of ad blocking and anti-tracking add-ons, which are some of the most popular.

In Jetpack's favor, it has a powerful module system similar to the one in node.js. However, given that JavaScript will soon have built-in support for modules, this won't be an advantage for long.

Finally, Jetpack doesn't solve the problem that add-on developers must code for two very different APIs. Basing WebExtensions off Chrome's API means that developers who stick to the common APIs will only have to maintain one codebase.

This WebExtension API sounds limiting

We certainly don't intend it to be. Our goal is for the WebExtension API to cover every reasonable use case that addon authors have.

Won't this limit experimentation

As is, it will. We are trying to devise a system that will allow for extension authors to have the flexibility to implement features that the WebExtension API doesn't currently allow. We will post more information about that when there is something solid to share. The intent is for add-on authors to experiment through this mechanism with the knowledge that there are no guarantees of compatibility between Firefox releases and use that to inform future additions to the WebExtension API

I already have a XUL extension. How is this not terrible news for me?

There is certainly some short term pain that we're inflicting, but we hope that the long term gains are worth it. In the short term (~18 months) you will need to rewrite your add-on to use the new APIs. However, after that, you're done! The intention is for the WebExtension API to be stable enough that addon authors can rely on it not to break between Firefox releases.

Why deprecate XUL now? Firefox is still using it internally.

Yes, Firefox is using XUL internally right now. But, Firefox is actively planning for the removal of XUL internally. That will translate into death by 100s of paper cuts (i.e. breakage with every release) for addons that depend on Firefox's usage of XUL as it is progressively removed from the product.