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.

How will WebExtensions be cross-browser if you're extending Google's API?

Unlike the web platform, we don't expect every browser to implement every aspect of WebExtensions in the same way. Hopefully there will be APIs that all browsers agree on, and they will work essentially the same way in all browsers. But there will also be APIs that are more browser-specific. For example, it's unlikely that Chrome will ever support a toolbar API, but Firefox probably will.

Even without perfect compatibility between browsers, a common API still has many advantages for extension developers. If developers stay within the common API, their extensions will automatically work across browsers. Even if developers choose to use browser-specific APIs, their extensions may be usable on other browsers through feature detection and fallbacks. For example, an extension using a toolbar API might be able to fall back to the browser action API on other browsers.

Which add-ons will stop working after the deprecation?

We don't want to limit what add-ons can do in Firefox. The process we've started is designed to understand how we can extend Firefox in ways that are less brittle than the current XUL/XPCOM system. We will work with every developer who is interested to make their add-on work in Firefox. That said, add-ons may be lost if they are unmaintained or have maintainers who lack the time to port their add-on.

I'm writing a new extension today. What API should I use?

That's a complex decision. If you already have a Chrome extension, it's probably best to wait until WebExtensions are ready for general purpose use. We expect that to take a few more months. You can consult the WebExtensions wiki to see whether the APIs you're using are supported or whether they're likely to be supported in the future.

If you're planning to write a new, Firefox-specific extension, the add-on SDK (Jetpack) may be your best option. It is well supported in older versions of Firefox and is well-documented. However, make sure to read "Multiprocess Firefox and the SDK" to ensure your add-on is compatible with Electrolysis.

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. Some discussion has already begun. 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.

It sounds like you've made decisions without community input

We're just getting started with WebExtensions, and have begun with a set of APIs that are commonly used with Chrome so people can kick the tires. We don't want to be a Chrome copy, and want to ensure we differentiate while integrating Electrolysis and other initatives into Firefox. To innovate will require input and assistance from the community, which we are actively seeking. The path for WebExtensions will evolve in the coming weeks, months, and years, and we want the developer community to be a big part of that evolution.

Are malicious addons really a problem?

Yes. Please read "The Case for Extension Signing".