Add-on Compatibility for Firefox 44

Jorge Villalobos


Firefox 44 will be released on January 26th. Here’s the list of changes that went into this version that can affect add-on compatibility. There is more information available in Firefox 44 for Developers, so you should also give it a look.





Let me know in the comments if there’s anything missing or incorrect on these lists. If your add-on breaks on Firefox 44, I’d like to know.

The automatic compatibility validation and upgrade for add-ons on AMO will happen in the coming weeks, so keep an eye on your email if you have an add-on listed on our site with its compatibility set to Firefox 43.

Loading temporary add-ons

Andy McKay


With Firefox 43 we’ve enabled add-on signing, which requires add-ons installed in Firefox to be signed. If you are running the Nightly or Dev Edition of Firefox, you can disable this globally by accessing about:config and changing the xpinstall.signatures.required value to false. In Firefox 43 and 44 you can do this on the Release and Beta versions, respectively.

In the future, however, disabling signing enforcement won’t be an option for the Beta and Release versions as Firefox will remove this option. We’ve released a signing API and the jpm sign command which will allow developers to get a signed add-on to test on stable releases of Firefox, but there is another solution in Firefox 45 aimed at add-on developers, which gives you the ability to run an unsigned, restartless add-on temporarily.

To enable this, visit a new page in Firefox, about:debugging:

Screen Shot 2015-12-18 at 8.07.12 AM

In my case I’ve got a new version of an add-on I’m developing; a new WebExtension called “Sort Tabs by URL”. To load this unsigned version temporarily, click on the “Load Temporary Add-on” and select the .xpi file for the add-on. This will load an unsigned add-on temporarily, for the duration of the current browser session. You can see this in about:debugging and also by the green button in the toolbar that the add-on creates:

Screen Shot 2015-12-18 at 8.07.42 AM

The add-on is only loaded temporarily; once you restart your browser, the add-on will no longer be loaded, and you’ll have to re-load it from the add-ons manager.

If you don’t want to go to the effort of making an .xpi of your add-on while developing – you can just select a file from within the add-on, and it will be loaded temporarily without having to make a zip file.

One last note, if you have an add-on installed and then install the an add-on temporarily with the same id then the older add-on is disabled and the new temporary add-on is used.

WebExtensions in Firefox 45

Andy McKay


In August we announced that work had begun on the WebExtensions API as the future of developing add-ons in Firefox. This post covers the progress we’ve made since then.

WebExtensions is currently in an alpha state, so while this is a great time to get involved, please keep in mind that things might change if you decide to use it in its current state. Since August, we’ve closed 77 bugs and ramped up the WebExtensions team at Mozilla. With the release of Firefox 45 in March 2016, we’ll have full support for the following APIs: alarms, contextMenus, pageAction and browserAction. Plus a bunch of partially supported APIs: bookmarks, cookies, extension, i18n, notifications, runtime, storage, tabs, webNavigation, webRequest, windows.

A full list of the API differences is available, and you can also follow along on the state of WebExtensions on All add-ons built with WebExtensions are fully compatible with a multiprocess Firefox and will work in Chrome and Opera.

Beyond APIs, support is being added to to enable developers to upload their add-ons and have them tested, that should be ready for Firefox 44. Documentation is being worked on in MDN and a set of example WebExtensions is available.

Over the coming months we will work our way towards a beta in Firefox 47 and the first stable release in Firefox 48. If you’d like to jump in to help, or get your API added, then please join us on our mailing list or at one of our public meetings.

Your contributions are appreciated!

Signing Firefox add-ons with jpm sign



With this week’s release of Firefox 43, all add-ons must now be signed. While this will make the block-list and other malware prevention measures more effective, add-on developers who wish to distribute outside of must now add signing to their release flow.

To make it easier for these developers, we released the add-on signing API last month. Today, we’re also providing a new version of the jpm command line tool that makes add-on signing even easier.


Install jpm for NodeJS from NPM like this:

npm install jpm

Generate API Credentials

In order to work with the signing API you first need to log in to the developer hub and generate API credentials.

Signing an Add-on

To begin signing an SDK-based add-on with jpm, change into the source directory and run this command:

jpm sign --api-key ${AMO_API_KEY} --api-secret ${AMO_API_SECRET}

This will fetch a signed XPI file to your current directory (or --addon-dir) that you can self-host for installation into Firefox. Read more about add-on distribution here. Since this XPI is intended for distribution outside of, it assumes you don’t want your add-on listed on This is referred to as an unlisted add-on.

Updating an Add-on

To sign a new version of your unlisted add-on, just increment the version number in your package.json file and re-run the jpm sign command.

Signing XPI Files Directly

If you aren’t using jpm to manage your add-on, you can still sign the XPI file directly, like this:

jpm sign --xpi /path/to/your-addon.xpi --api-key ... --api-secret ...

Signing Requirements

We recently made changes to the signing requirements for add-ons not listed on We still do some basic checks to make sure that the add-on is well formed enough to install without errors but if those checks pass, any add-on will be signed.

Keep in mind that signing is only required for distributing your add-on. You can always install unsigned add-ons into a development version of Firefox for testing purposes.

Listed Add-ons

The jpm sign command currently doesn’t support add-ons distributed on (referred to as listed add-ons) at the moment. Listed add-ons still require a manual review.

Going Further

We hope that the jpm command eases the development burden introduced by signing. See the jpm sign reference documentation for more options, features, and examples. As usual, please report bugs if you run into any.

December 2015 Featured Add-ons

Amy Tsay


Pick of the Month: Fox Web Security

by Oleksandr
Fox Web Security is designed to automatically block known dangerous websites and unwanted content that is not suitable for children.

“This add-on is extremely fast and effective! You can say goodbye to porno sites, scams and viruses—now my web is absolutely safe.”

Featured: YouTube™ Flash-HTML5

by A Ulmer
YouTube™ Flash-HTML allows you to play YouTube Videos in Flash or HTML5 player.

Featured: AdBlock for YouTube™

by AdblockLite
AdBlock for YouTube™ removes all ads from YouTube.

Featured: 1-Click YouTube Video Download

by The 1-Click YouTube Video Download Team
The simplest YouTube Video Downloader for all YouTube Flash sites, period.

Nominate your favorite add-ons

Featured add-ons are selected by a community board made up of add-on developers, users, and fans. Board members change every six months, so there’s always an opportunity to participate. Stayed tuned to this blog for the next call for applications.

If you’d like to nominate an add-on for featuring, please send it to for the board’s consideration. We welcome you to submit your own add-on!

De-coupling Reviews from Signing Unlisted Add-ons

Kev Needham


tl;dr – By the end of this week (December 4th), we plan to completely automate the signing of unlisted add-ons and remove the trigger for manual reviews.

Over the past few days, there have been discussions around the first step of the add-on signing process, which involves a programmatic review of submissions by a piece of code known as the “validator”. The validator can trigger a manual review of submissions for a variety of reasons and halt the signing process, which can delay the release of an add-on because of the signing requirement that will be enforced in Firefox 43 and later versions.

There has been debate over whether the validator is useful at all, since it is possible for a malicious player to write code that bypasses it. We agree the validator has limitations; the reality is we can only detect what we know about, and there’s an awful lot we don’t know about. But the validator is only one component of a review process that we hope will make it easier for developers to ship add-ons, and safer for people to use them. It is not meant to be a catch-all malware detection utility; rather, it is meant to help developers get add-ons into the hands of Firefox users more expediently.

With that in mind, we are going to remove validation as a gating mechanism for unlisted add-ons. We want to make it easier for developers to ship unlisted add-ons, and will perform reviews independently of any signing process. By the end of this week (December 4th), we plan to completely automate the signing of unlisted add-ons and remove the trigger for manual reviews. This date is contingent on how quickly we can make the technical, procedural, and policy changes required to support this. The add-ons signing API, introduced earlier this month, will allow for a completely automated signing process, and will be used as part of this solution.

We’ll continue to require developers to adhere to the Firefox Add-ons policies outlined on MDN, and would ask that they ensure their add-ons conform to those polices prior to submitting them for signing. Developers should also be familiar with the Add-ons Reviewer Guide, which outlines some of the more popular reasons an add-on would fail a review and be subject to blocklisting.

I want to thank everyone for their input and insights over the last week. We want to make sure the experience with Firefox is as painless as possible for Add-on developers and users, and our goals have never included “make life harder”, even if it sometimes seems that way. Please continue to speak out, and feel free to reach out to me or other team members directly.

I’ll post a more concrete overview of the next steps as they’re available, and progress will be tracked in bug 1229197. Thanks in advance for your patience.


Add-ons Update – Week of 2015/11/25

Jorge Villalobos


I post these updates every 3 weeks to inform add-on developers about the status of the review queues, add-on compatibility, and other happenings in the add-ons world.

The Review Queues

In the past 3 weeks, 758 add-ons were reviewed:

  • 602 (79%) were reviewed in less than 5 days.
  • 32 (4%) were reviewed between 5 and 10 days.
  • 124 (16%) were reviewed after more than 10 days.

There are 281 listed add-ons awaiting review, and 189 unlisted add-ons awaiting review. I should note that this is an unusually large number of unlisted add-ons, which is due to a mass uploading by a developer with 100+ add-ons.

Review times for most add-ons have improved recently  due to more volunteer activity. Add-ons that are admin-flagged or very complex are now getting much needed attention, thanks to a new contractor reviewer. There’s still a fairly large review backlog to go through.

If you’re an add-on developer and would like to see add-ons reviewed faster, please consider joining us. Add-on reviewers get invited to Mozilla events and earn cool gear with their work. Visit our wiki page for more information.

Firefox 43 Compatibility

This compatibility blog post is now public. The bulk compatibility validation should be run soon.

As always, we recommend that you test your add-ons on Beta and Firefox Developer Edition to make sure that they continue to work correctly. End users can install the Add-on Compatibility Reporter to identify and report any add-ons that aren’t working anymore.

Changes in let and const in Firefox 44

Firefox 44 includes some breaking changes that you should all be aware of. Please read the post carefully and test your add-ons on Nightly or the newest Developer Edition.

Extension Signing

The wiki page on Extension Signing has information about the timeline, as well as responses to some frequently asked questions. The current plan is to turn on enforcement by default in Firefox 43.


Electrolysis, also known as e10s, is the next major compatibility change coming to Firefox. In a nutshell, Firefox will run on multiple processes now, running content code in a different process than browser code.

This is the time to test your add-ons and make sure they continue working in Firefox. We’re holding regular office hours to help you work on your add-ons, so please drop in on Tuesdays and chat with us!

Web Extensions

If you read the post on the future of add-on development, you should know there are big changes coming. We’re investing heavily on the new WebExtensions API, so we strongly recommend that you start looking into it for your add-ons. You can track progress of its development in

A New Firefox Add-ons Validator

Matthew Riley MacPherson


The state of add-ons has changed a lot over the past five years, with Jetpack add-ons rising in popularity and Web Extensions on the horizon. Our validation process hasn’t changed as much as the ecosystem it validates, so today Mozilla is announcing we’re building a new Add-ons Validator, written in JS and available for testing today! We started this project only a few months ago and it’s still not production-ready, but we’d love your feedback on it.

Why the Add-ons Validator is Important

Add-ons are a huge part of why people use Firefox. There are currently over 22,000 available, and with work underway to allow Web Extensions in Firefox, it will become easier than ever to develop and update them.

All add-ons listed on (AMO) are required to pass a review by Mozilla’s add-on review team, and the first step in this process is automated validation using the Add-ons Validator.

The validator alerts reviewers to deprecated API usage, errors, and bad practices. Since add-ons can contain a lot of code, the alerts can help developers pinpoint the bits of code that might make your browser buggy or slow, among other problems. It also helps detect insecure add-on code. It helps keep your browsing fast and safe.

Our current validator is a bit old, and because it’s written in Python with JavaScript dependencies, our old validator is difficult for add-on developers to install themselves. This means add-on developers often don’t know about validation errors until they submit their add-on for review.

This wastes time, introducing a feedback cycle that could have been avoided if the add-on developer could have just run addons-validator myAddon.xpi before they uploaded their add-on. If developers could easily check their add-ons for errors locally, getting their add-ons in front of millions of users is that much faster.

And now they can!

The new Add-ons Validator, in JS

I’m not a fan of massive rewrites, but in this case it really helps. Add-on developers are JavaScript coders and nearly everyone involved in web development these days uses Node.js. That’s why we’ve written the new validator in JavaScript and published it on npm, which you can install right now.

We also took this opportunity to review all the rules the old add-on validator defined, and removed a lot of outdated ones. Some of these hadn’t been seen on AMO for years. This allowed us to cut down on code footprint and make a faster, leaner, and easier-to-work-with validator for the future.

Speaking of which…

What’s next?

The new validator is not production-quality code yet and there are rules that we haven’t implemented yet, but we’re looking to finish it by the first half of next year.

We’re still porting over relevant rules from the old validator. Our three objectives are:

  1. Porting old rules (discarding outdated ones where necessary)
  2. Adding support for Web Extensions
  3. Getting the new validator running in production

We’re looking for help with those first two objectives, so if you’d like to help us make our slightly ambitious full-project-rewrite-deadline, you can…

Get Involved!

If you’re an add-on developer, JavaScript programmer, or both: we’d love your help! Our code and issue tracker are on GitHub at We keep a healthy backlog of issues available, so you can help us add rules, review code, or test things out there. We also have a good first bug label if you’re new to add-ons but want to contribute!

If you’d like to try the next-generation add-ons validator, you can install it with npm: npm install addons-validator. Run your add-ons against it and let us know what you think. We’d love your feedback as GitHub issues, or emails on the add-on developer mailing list.

And if you’re an add-on developer who wishes the validator did something it currently doesn’t, please let us know!

We’re really excited about the future of add-ons at Mozilla; we hope this new validator will help people write better add-ons. It should make writing add-ons faster, help reviewers get through add-on approvals faster, and ultimately result in more awesome add-ons available for all Firefox users.

Happy hacking!

Test your add-ons for Multi-process Firefox compatibility

Amy Tsay


You might have heard the news that future versions of Firefox will run the browser UI separately from web content. This is called Multi-process Firefox (also “Electrolysis” or “e10s”), and it is scheduled for release in the first quarter of 2016.

If your add-on code accesses web content directly, using an overlay extension, a bootstrapped extension, or low-level SDK APIs like window/utils or tabs/utils, then you will probably be affected.

To minimize the impact on users of your add-ons, we are urging you to test your add-ons for compatibility. You can find documentation on how to make them compatible here.

Starting Nov. 24, 2015, we are available to assist you every Tuesday in the #addons channel at Click here to see the schedule. Whether you need help testing or making your add-ons compatible, we’re here to help!

Signing API now available

Andy McKay


Over the years, has had many APIs. These are used by Firefox and other clients to provide add-on listings, blocklists, and other features. But there hasn’t really been an API that developers can interact with. As part of ongoing improvements to the site, we’ve started focusing on producing APIs for add-on developers as well.

Our first one aims to make add-on signing a little easier for developers. This API enables you to upload an XPI and get back the signed add-on if it passes all the validation checks.

To use this API, log in to and go to Tools > Manage API Keys. Then agree to the terms and fetch an API key and secret to use in subsequent API calls.


Once you’ve done that, generate authorization tokens and use the documented API to sign your add-on.

The documented examples use curl to interact with the API. For example:

-XPUT --form 'upload=@build/my-addon.xpi' -H 'Authorization: JWT your-jwt-token'

This is just the first of the APIs that we hope to add to the site and a path that we hope will lead to increased functionality throughout the add-ons ecosystem. This feature is under development, so we are keen to hear feedback or any issues.