Extension Signing: Availability of Unbranded Builds

With the release of Firefox 48, extension signing can no longer be disabled in the release and beta channel builds by using a preference. As outlined when extension signing was announced, we are publishing specialized builds that support this preference so developers can continue to test against the code that beta and release builds are generated from. These builds do not use Firefox branding, do not update automatically, and are available for the en-US locale only.

You can find links to the latest unbranded beta and release builds on the Extension Signing page as they come out. Additional information on Extension Signing, including a Frequently Asked Questions section, is also available on this page.

Linting and Automatically Reloading WebExtensions

We recently announced web-ext 1.0, a command line tool that makes developing WebExtensions more of a breeze. Since then we’ve fixed numerous bugs and added two new features: automatic extension reloading and a way to check for “lint” in your source code.

You can read more about getting started with web-ext or jump in and install it with npm like this:

npm install --global web-ext

Automatic Reloading

Once you’ve built an extension, you can try it out with the run command:

web-ext run

This launches Firefox with your extension pre-installed. Previously, you would have had to manually re-install your extension any time you changed the source. Now, web-ext will automatically reload the extension in Firefox when it detects a source file change, making it quick and easy to try out a new icon or fiddle with the CSS in your popup until it looks right.

Automatic reloading is only supported in Firefox 49 or higher but you can still run your extension in Firefox 48 without it.

Checking For Code Lint

If you make a mistake in your manifest or any other source file, you may not hear about it until a user encounters the error or you try submitting the extension to addons.mozilla.org. The new lint command will tell you about these mistakes so you can fix them before they bite you. Run it like this:

web-ext lint

For example, let’s say you are porting an extension from Chrome that used the history API, which hasn’t fully landed in Firefox at the time of this writing. Your manifest might declare the history permission like this:

  "manifest_version": 2,
  "name": "My Extension",
  "version": "1.0",
  "permissions": [

When running web-ext lint from the directory containing this manifest, you’ll see an error explaining that history is an unknown permission.

Try it out and let us know what you think. As always, you can submit an issue if you have an idea for a new feature of if you run into a bug.

New WebExtensions Guides and How-tos on MDN

The official launch of WebExtensions is happening in Firefox 48, but much of what you need is already supported in Firefox and AMO (addons.mozilla.org). The best place to get started with WebExtensions is MDN, where you can find a trove of helpful information. I’d like to highlight a couple of recent additions that you might find useful:

Thank you to Will Bamberg for doing the bulk of this work. Remember that MDN is a community wiki, so anyone can help!

Completing Firefox Accounts on AMO

In Feburary we rolled out Firefox Accounts on addons.mozilla.org (AMO). That first phase created a migration flow from old AMO accounts over to Firefox Accounts. Since then, 84% of developers who have logged in have transitioned over to a Firefox Account.

The next step is to remove the ability to log in using an old AMO account. Once this is complete, the only way to log in to AMO is by using Firefox Accounts.

If you have an old account on AMO and have not gone through the migration flow, you can still access your account if the email you use to log in through Firefox Accounts is the same as the one previously registered on AMO.

We expect that the removal of old logins will be completed in a couple of weeks, unless any unforeseen problems occur.

Frequently asked questions

What happens to the add-ons I develop when I convert to a new Firefox Account?

All the add-ons are accessible to the new Firefox Account.

Why do I want a Firefox Account?

Firefox Accounts is the identity system that is used to synchronize Firefox across multiple devices. Many Firefox products and services will soon begin migrating over, simplifying your sign-in process and making it easier for you to manage all your accounts.

Where do I change my password?

Once you have a Firefox Account, you can go to accounts.firefox.com, sign in, and click on Password.

If you have forgotten your current password:

  1. Go to the AMO login page
  2. Click on I forgot my password
  3. Proceed to reset the password

A Better Add-on Discovery Experience

People who personalize Firefox like their Firefox better. However, many people don’t know that they can, and for those who know it isn’t particularly easy to do. So a few months ago, we began rethinking our entire add-on discovery experience—from helping people understand the benefits of personalization, to making it easier to install an add-on, to putting the right add-on in front of people at the right time.

The first step we’ve taken towards a better discovery experience is in the redesign of our Add-on Discovery Pane. This is typically the first page users see when they launch the Add-on Manager at about:addons.

Add-on Discovery Pane before Firefox 48

Add-on Discovery Pane before Firefox 48

We updated this page to target people who are just getting started with add-ons, by simplifying add-on installation to just one click and using clean images and text to quickly orient a new user.

Disco Pane One Click Install

It features a tightly curated list of add-ons that provide customizations that are easy for new users to understand.

Add-on Discovery Pane starting with Firefox 48

Add-on Discovery Pane starting with Firefox 48

We started with a small list and collaborated with their developers to ensure the best possible experience for users. For future releases, we will refresh the featured content on a more frequent basis and open up the nomination process for inclusion.

Our community of developers create awesome add-ons, and we want to help users discover them and love their Firefox even more. In the coming months, we are going to continue improving the experience by making recommendations that are as uniquely helpful to users as possible.

In the meantime, this first step toward improving the Firefox personalization experience will land in Firefox 48 on August 1, and is available in Firefox Beta now. So download Firefox Beta, go to about:addons and give it a try! (You can also reach this page by going to the Tools menu and choosing “Add-ons”). We would love to hear your feedback in the forums.

Writing an opt-in UI for an extension

Our review policies for addons.mozilla.org (AMO) require transparency when it comes to an add-on’s features and how they might affect a user’s privacy and security.

These policies are particularly relevant in cases where an add-on includes monetization features that are unrelated to its main function. For example, a video downloader add-on could include a shopping recommendation feature that injects offers from commercial websites. In cases like this, to be listed on AMO the feature would need to be opt-in. Opt-in means the add-on needs to present to the user the option to enable the feature, with a default action of keeping it disabled.

We’re often asked for examples of add-ons that do this, so I decided to create a sample WebExtension for this purpose. You can find the code on GitHub, and the built and signed example can be downloaded here.

The extension implements two opt-in prompts:

  1. A new tab. Tab opt-in
  2. A panel in the main add-on button. Panel opt-in

(If you don’t recognize the dark theme in the screenshots, it’s because I’m using Firefox Developer Edition—currently Firefox 49—for testing.)

An add-on would normally implement one prompt or the other. Opening a new tab has the advantage of getting the user’s attention right away, and has more room for content. The main disadvantage is that it can annoy users and feel too pushy. The pop-up approach is more user-friendly because it appears when the user is ready to engage with the add-on and is better integrated with the add-on UI. However, it wouldn’t work if the add-on doesn’t include buttons.

This example is completely minimal, hence the almost complete lack of styling. However, it includes the elements that AMO policies deem necessary:

  • Text explaining clearly to the user what the opt-in feature does and why it’s being offered. In this case, the extra feature is a variation of the borderify example on GitHub.
  • A link to a privacy policy and/or more information about the feature. That page should spell out its privacy and security implications.
  • A clear choice between enabling the feature and keeping it disabled, defaulting to disabled. I set autofocus="true" to the Cancel button, which can be clearly seen in the popup screenshot.

Hitting the Return key in either case, or closing the opt-in tab should be assumed to mean that the user is choosing not to accept the feature (the tab closing case isn’t implemented in this example to make it easier to test). The example uses the storage API to keep track of two flags: one that indicates the user has clicked on either button, and one that indicates if the user has enabled the feature or not. After the opt-in is registered as shown, the tab won’t show up again, and the content changes to something else.

Note: I couldn’t find a way to look at the extension’s storage in the developer tools (I suppose it’s not implemented yet). You can clear the storage to reset the state of the extension by deleting the browser-extension-data folder in the profile.

Remember that sneaking in unwanted features is bad for your users and your add-on’s reputation, so make sure you give your users control and give them clear information to make a decision. Happy coding!

WebExtensions support on AMO

It’s been possible to submit WebExtensions add-ons to addons.mozilla.org (AMO) since February, but I wanted to take a moment to highlight some of the improvements we’ve made since then that make it much easier to get your Chrome or Opera add-on into AMO.

These features have all been deployed to AMO over the last couple of months and are available for use.

New linter

We are now using the add-ons linter for WebExtensions which means that when we parse a WebExtensions add-on, we are running through a new JavaScript-powered linter, instead of the Python one. This parsing occurs each time you upload a new add-on or a new version of an add-on.

It uses eslint to parse the JavaScript and a schema to verify that the WebExtensions manifest is correct. Because we’ve started to implement functionality in the new add-ons linter that didn’t exist in the old version, more things will be showing up as warnings.

As an example, if you request a permission in the manifest that Firefox doesn’t support, you’ll get a warning:


Relaxed upload criteria

If you’ve developed and add-on for Chrome or Opera, we’d like you to upload it to AMO. For this reason, we’ve relaxed a few criteria around AMO. Once you’ve verified that an add-on works correctly using about:debugging, you should then be able to upload it to AMO quite easily. We’ve hopefully made this easier through the following steps:

Optional add-on id

If your WebExtension does not have an id specified in the manifest.json, then AMO will generate an id for your add-on and add it to the add-on signing process. You can then get the add-on id from AMO and re-use that in later API calls, if needed.

The command line tool web-ext also supports optional ids.


AMO will now accept an add-on as a zip file or a crx file. It will still only emit xpi files that Firefox and other Mozilla projects can consume. In the case of a crx file, the extra data added by the Chrome store will be stripped out of the file.

We recommend using a tool like web-ext to generate the appropriate file for your add-on.

Comments in the manifest file

Although comments are not valid in a JSON file, Chrome supports comments in the manifest.json file. To keep compatibility with Chrome, the addons-linter and hence AMO now support comments in the manifest file, but only comments starting with a double slash (//).


Finally, AMO now supports translations in the manifest. This again follows the Chrome standard, so that:

//in manifest.json:
"default_locale": "en",
"name": "__MSG_appName__",

//in _locales/en/messages.json:
  "appName": {
    "message": "My Add-on",
    "description": "The name of the add-on."

//in _locales/de/messages.json:
  "appName": {
    "message": "Mein Add-on"

The manifest will be parsed and the translations automatically entered into AMO. You need to ensure that default_locale is set in the manifest for the localisations to be activated. On the first upload, AMO will process the translations:

Screenshot 2016-07-14 09.44.11

If you’d like to get involved then join our mailing list or check out our repositories on Github.

Add-ons Update – Week of 2016/07/13

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, 1278 listed add-ons were reviewed:

  • 1194 (93%) were reviewed in fewer than 5 days.
  • 62 (5%) were reviewed between 5 and 10 days.
  • 22 (2%) were reviewed after more than 10 days.

There are 74 listed add-ons awaiting review.

You can read about the recent improvements in the review queues here.

If you’re an add-on developer and are looking for contribution opportunities, please consider joining us. Add-on reviewers are critical for our success, and can earn cool gear for their work. Visit our wiki page for more information.


The compatibility blog post for Firefox 48 is up, and the bulk validation was run. The post for Firefox 49 is also up and the bulk validation will be run in the coming weeks.

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.

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 remove the signing override preference in Firefox 48. The unbranded builds, which were the final piece, are available here. We will update the Extension Signing doc with more information about how to obtain them.


We would like to thank these people for their recent contributions to the add-ons world: Sylwia Ornatowska, dw-dev, Lavish Aggarwal, Baris Derin, Martin Giger, Viswaprasath, gorf4673, and Atique Ahmed Ziad.

You can read more about their contributions in our recognition page.

July 2016 Featured Add-ons

Firebug console panel view with an example of error logs.

Firebug console panel view with an example of error logs.

Pick of the Month: Firebug

by Firebug Working Group
Access a bevy of development tools while you browse—edit, debug, and monitor CSS, HTML, and JavaScript live in any Web page.

”One of the main reasons why I love Firefox. Cannot imagine Firefox without Firebug.”

Featured: ipFood

by hg9x
Browse the Web anonymously by generating random proxies.

”Everything works perfectly.”

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. Here’s further information on AMO’s featured content policies.

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

Mozlondon Debriefer

teamFrom June 13 – 17, more than a thousand Mozillians descended on London to celebrate the accomplishments of the past six months and collaborate on priorities for the latter half of the year. The add-ons team and a handful of volunteers did just that, and we wanted to share some of the highlights.

Add-on reviews

We celebrated the fact that review times have dropped dramatically in 2016. Last year, most add-on submissions got clogged in the review queue for 10 or more days. Now, 95% of submissions are reviewed in under five days (84% in less than 24 hours!). This is a huge boon to our developer community and a great credit to our tireless, mostly-volunteer review team.

Review efficacy should continue to trend positively over the balance of this year. We furthered plans to simplify the review process by eliminating preliminary reviews, among other streamlining initiatives.


It’s likely not a surprise to learn that WebExtensions dominated engineering discussions in London. Here are a few top-level items…

… A WebExtensions Advisory Group has been formed. This cross-disciplinary body is primarily tasked with providing input around the development of future APIs.

… We saw some inspired demos, like runtime.connectNative, which will allow add-ons to communicate out of process; and the auto-reload function for WebExtensions (set to land in 49); plus a demo of a hybrid add-on that allows an SDK add-on to embed a WebExtension add-on, allowing developers to start using the WebExtension API and migrate their users.

… Prioritized future work for WebExtensions was solidified, including permissions support, Chrome parity support for top Chrome content, and end-to-end automated installation testing.

… We recapped many recent WebExtensions advancements, such as the implementation of dozens of new APIs (e.g. history, commands, downloads, webNavigation, etc.)

Community & Editorial

It’s worth recognizing all the diverse ways our community contributes to the success of add-ons—coders, content reviewers, curators, translators, tech writers, evangelists, student ambassadors, and more—our community is integral in providing Firefox users with the power to personalize their Web experience and AMO’s ability to support a massive ecosystem of more than 32,000 extensions and 400,000 themes.

One of the focal points of our community discussions in London was: How can we do more to move volunteers up the contribution curve, so we can nurture the next generation of leaders? What more can we do to turn bug commenters into bug fixers, developers into evangelists, and so forth? Check out the notes from this session and add your ideas there!

On the editorial side, we started exploring ways of re-thinking content discovery. Of course we have the AMO site as a content discovery destination with more than 15 million monthly users, but research tells us the majority of Firefox users hardly know what an add-on is, let alone where to find one. So how can we introduce the wonder of add-ons to a broader Firefox audience?

A general consensus emerged—we need to take the content to where the user is, to key moments in their everyday Web experience where perhaps an add-on can address a need. This is just one of the projects we’ll begin tackling in the second half of the year. If you’d like to get involved, you’re invited to join our weekly public UX meeting.

To get involved with the add-ons world, please visit our wiki page, or get in touch with us at irc.mozilla.org in the #addons channel.