Bill McCloskey's Blog

Firefox Add-on Changes


This post is related to “The Future of Developing Firefox Add-ons” on the add-ons blog. Please read that first for context. A couple of concerns from that post have come up that I would like to address here.

One concern people have is that their favorite add-on is no longer going to be supported, especially add-ons for power users. Some of the ones being mentioned are:

We have a lot of ideas about how to make these sorts of extensions work using better APIs than we have now.

We’re hoping people will have a lot of other ideas for the extensions that they care about. If you’d like to propose or vote on ideas, please visit to express your opinion.

There are also concerns that restricting people to the WebExtensions API will limit innovation: we can make APIs to support the XUL extensions people have already made, but how will we know what other ones we’re missing out on?

It’s likely that we’ll still allow some access to XUL in the future. We want people to be able to experiment with new ideas, and they shouldn’t have to wait for us to design, implement, and finalize a new API. However, we don’t want this to become another feature like require('chrome') in Jetpack, which is used by virtually every add-on. We’re still trying to figure out how to avoid that fate. We know that we need to be more proactive about providing APIs that add-ons need. But is that enough?

Our big fear is that, once we provide a WebExtensions API, there won’t be anything to motivate people to switch over to it. We can try to deprecate access to the parts of XPCOM used to implement the functionality, but often there won’t be a clear mapping between the old and the new APIs.

Again, we’re open to ideas about how to do this. Moving away from XUL will be a long process. We’re announcing all of this early so that we can begin to gather feedback. APIs that are created in a vacuum probably aren’t going to be very useful to people.