WebExtensions/FAQ

This FAQ, like WebExtensions, will be evolving over the coming weeks. Additional information will follow, and we'll update the WebExtensions page as we post more detailed information.

It sounds like you've made decisions without community input, why?

We believe that moving Firefox away from XUL and XPCOM is a long-term strategic necessity. We need to find a way to do that. We have announced WebExtensions and the deprecation as early as possible so that we can get feedback from the community on how to make the transition. We know that WebExtensions will need to be improved. 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.

It sounds like you're copying Google...

The Chrome extension API was designed to work well with process separation and we are taking inspiration from it and copying functionality where it makes sense. However, there will be differences, and the goal of WebExtensions is not to copy Chrome or allow Chrome extensions to run unmodified in Firefox, but to simplify cross-browser development by providing commonly-supported methods and interfaces. We won't implement all of Chrome's APIs, and Chrome is unlikely to implement some of the APIs we add. Imagine the APIs as a Venn diagram. In the middle are cross-browser APIs for content scripts, tabs, and windows. In the Firefox side are APIs for toolbars and other UI elements. On the Chrome side are APIs for Google's cloud services.

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. But, 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 should work with minimal (or no!) modifications across browsers. Even if developers choose to use browser-specific APIs, their extensions may be usable on other browsers through feature detection and fallbacks. As an example, an extension using a toolbar API might be able to fall back to a browser action API on other browsers.

Why WebExtensions and not Jetpack?

There are a number of reasons we chose to focus development on the WebExtension API. First, there are more Chrome extensions than Jetpack add-ons and more developers who will be familiar with developing WebExtensions. WebExtensions has built-in support for content blocking, which is used by many ad-blocking and anti-tracking extensions that are popular; Jetpack lacks such APIs. Jetpack won't solve the problem that add-on developers must maintain a different codebase for each browser. Basing our initial implementation of WebExtensions off of Chrome's API means that developers who stick to the common APIs will be able to work off of a common codebase, and port extensions more simply between browsers.

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.

Which add-ons will stop working when XUL/XPCOM is deprecated?

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, and work to provide the functionality required in as many cases as possible. That said, there is a risk that some add-ons may not transition if they are not maintained 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 until WebExtensions matures. Jetpack 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.

Won't this limit experimentation?

If WebExtensions were ultimately limited to the Chrome model, it would. But we're actually designing a system providing extension authors with the flexibility to implement innovative 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 stable WebExtension API.

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.

Why keep the .xpi packaging format?

We're using JAR signing for WebExtensions, and Chrome uses a different system. Since signing is necessarily browser-specific, integrating the two would be difficult, and maintaining the current packaging extension for Firefox makes sense. The only part of the XPI file format that WebExtensions uses is the filename suffix, and there may be some changes to the final extension we use as we seek (and get) more feedback.

Are malicious addons really a problem?

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