Extension review wait times are about to get much shorter

One the of the main advantages of the new WebExtensions API is that it is less likely to cause security or stability problems for users. This means we can review these add-ons faster, and we have adapted our review flow accordingly. For the past few months we have reduced review wait times for add-ons written using the WebExtensions API. Today we’re taking another big step in that direction.

Add-ons built on the WebExtensions API will now be automatically reviewed. This means we will publish add-ons shortly after uploading. Human reviewers will look at these pre-approved add-ons, prioritized on various risk factors that are calculated from the add-on’s codebase and other metadata. This change is now live, and we plan to continue augmenting it in the coming months.

These changes give developers a much improved upload and publishing experience, but also comes with more responsibility on their end. Issues that arise during review can still lead to rejection of a version or a whole listing. This will now happen after publication, rather than before. We’re in the process of editing a new Review Policy that will make the rules, exceptions, and consequences clearer for everyone.

Add-ons Update – 2017/09

Here’s your monthly add-ons update.

The Review Queues

In the past month, our team reviewed 2,490 listed add-on submissions:

  • 2,074 in fewer than 5 days (83%).
  • 89 between 5 and 10 days (4%).
  • 327 after more than 10 days (13%).

244 listed add-ons are awaiting review.

If you’re an add-on developer and are looking for contribution opportunities, please consider joining us. Visit our wiki page for more information.

Compatibility Update

We published the blog post for 56 and the bulk validation has been run. This is the last one of these we’ll do, since compatibility is a much smaller problem with the WebExtensions API.

Firefox 57 is now on the Nightly channel and will soon hit Beta, only accepting WebExtension add-ons by default. Here are some changes we’re implementing on AMO to ease the transition to 57.

Recognition

We would like to thank the following people for their recent contributions to the add-ons world:

  • Amola Singh
  • yfdyh000
  • bfred-it
  • Tiago Morais Morgado
  • Divya Rani
  • angelsl
  • Tim Nguyen
  • Atique Ahmed Ziad
  • Apoorva Pandey
  • Kevin Jones
  • ljbousfield
  • asamuzaK
  • Rob Wu
  • Tushar Sinai
  • Trishul Goel
  • zombie
  • tmm88
  • Christophe Villeneuve
  • Hemanth Kumar Veeranki

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

Last chance to migrate your legacy user data

If you are working on transitioning your add-on to use the WebExtensions API, you have until about mid-October (a month before Firefox 57 lands to allow time for testing and migrating), to port your legacy user data using an Embedded WebExtension.

This is an important step in giving your users a smooth transition because they can retain their custom settings and preferences when they update to your WebExtensions version. After Firefox 57 reaches the release channel on November 13, you will no longer be able to port your legacy data.

If you release your WebExtensions version after the release of Firefox 57, your add-on will be enabled again for your users and they will still keep their settings if you port the data beforehand. This is because WebExtensions APIs cannot read legacy user settings, and legacy add-ons are disabled in Firefox 57. In other words, even if your WebExtensions version won’t be ready until after Firefox 57, you should still publish an Embedded WebExtension before Firefox 57 in order to retain user data.

When updating to your new version, we encourage you to adopt these best practices to ensure a smooth transition for your users.

Tell your users what to expect in your WebExtensions version

The migration to WebExtensions APIs is picking up steam, with thousands of compatible add-ons now available on addons.mozilla.org (AMO). To ensure a good experience for the growing number of users whose legacy add-ons have been updated to WebExtensions versions, we’re encouraging developers to adopt the following best practices.

(If your new version has the same features and settings as your legacy version, your users should get a seamless transition once you update your listing, and you can safely ignore the rest of this post.)

If your new version has different features, is missing legacy features, or requires additional steps to recover custom settings, please do one or both of the following.

Update your AMO listing description

If your new version did not migrate with all of its legacy features intact, or has different features, please let your users know in the “About this Add-on” section of your listing.

If your add-on is losing some of its legacy features, let your users know if it’s because they aren’t possible with the WebExtensions API, or if you are waiting on bug fixes or new APIs to land before you can provide them. Include links to those bugs, and feel free to send people to the forum to ask about the status of bug fixes and new APIs.

Retaining your users’ settings after upgrade makes for a much better experience, and there’s still time to do it using Embedded WebExtensions. But if this is not possible for you and there is a way to recover them after upgrade, please include instructions on how to do that, and refer to them in the Version notes. Otherwise, let your users know which settings and preferences cannot be recovered.

Add an announcement with your update

If your new version is vastly different from your legacy version, consider showing a new tab to your users when they first get the update. It can be the same information you provide in your listing, but it will be more noticeable if your users don’t have to go to your listing page to see it. Be sure to show it only on the first update so it doesn’t annoy your users.

To do this, you can use the runtime.onInstalled API which can tell you when an update or install occurs:

function update(details) {

if (details.reason === 'install' || details.reason === 'update') {

browser.tabs.create({url: 'update-notes.html'});

}

}

browser.runtime.onInstalled.addListener(update);

This will open the page update-notes.html in the extension when the install occurs. For example:

For greater control, the runtime.onInstalled event also lets you know when the user updated and what their previous version was so you can tailor your release notes.

Thank you

A big thanks to all the developers who have put in the effort to migrate to the WebExtensions API. We are here to support you, so please reach out if you need help.

September’s Featured Extensions

Firefox Logo on blue background

Pick of the Month: Search Image

by Didier Lafleur
Highlight any text and perform a Google image search with a couple clicks.

“I’ve been looking for something like this for years, to the point I wrote my own script. This WORKS for me.”

Featured: Cookie AutoDelete

by Kenny Do
Automatically delete stagnant cookies from your closed tabs. Offers whitelist capability, as well.

“Very good replacement for Self-Destructing Cookies.”

Featured: Tomato Clock

by Samuel Jun
A super simple but effective time management tool. Use Tomato Clock to break your work bursts into meaningful 25-minute “tomato” intervals.

“A nice way to track my productivity for the day.”

Featured: Country Flags & IP Whois

by Andy Portmen
This extension will display the country flag of a website’s server location. Simple, informative.

“It does what it should.”

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. 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 [at] mozilla [dot] org for the board’s consideration. We welcome you to submit your own add-on!

Add-ons Update – 2017/08

Here’s the monthly update of the state of the add-ons world.

The Review Queues

In the past month, our team reviewed 1,803 listed add-on submissions:

  • 1368 in fewer than 5 days (76%).
  • 147 between 5 and 10 days (8%).
  • 288 after more than 10 days (16%).

274 listed add-ons are awaiting review.

If you’re an add-on developer and are looking for contribution opportunities, please consider joining us. Visit our wiki page for more information.

Compatibility Update

We published the blog post for 56 and the bulk validation has been run. This is the last one of these we’ll do, since compatibility is a much smaller problem with the WebExtensions API.

Firefox 57 is now on the Nightly channel, and only accepting WebExtension add-ons by default. Here are some changes we’re implementing on AMO to ease the transition to 57.

We recommend that you test your add-ons on Beta. If you’re an add-ons user, you can install the Add-on Compatibility Reporter. It helps you identify and report any add-ons that aren’t working anymore.

Recognition

We would like to thank the following people for their recent contributions to the add-ons world:

  • Apoorva Pandey
  • Neha Tekriwal
  • Swapnesh Kumar Sahoo
  • rctgamer3
  • Tushar Saini
  • vishal-chitnis
  • Cameron Kaiser
  • zombie
  • Trishul Goel
  • Krzysztof Modras
  • Tushar Saini
  • Tim Nguyen
  • Richard Marti
  • Christophe Villeneuve
  • Jan Henning
  • Leni Mutungi
  • dw-dev
  • Dino Herbert

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

WebExtensions in Firefox 56

Firefox 56 landed in Beta this week, so it’s time for another update on the WebExtensions transition. Documentation for the APIs discussed here can be found on MDN Web Docs.

API changes

The browsingData API can now remove cookies by host. The initial implementation of browsingData has landed for Android with support for the settings and removeCookies APIs.

The contextMenus API also has a few improvements. The text of the link is now included in the onClickData event and text selection is no longer limited to 150 characters. Optional permission requests can now also be triggered from context menus.

An alternative, more general namespace was added, called browser.menus. It supports the same API and all existing menu contexts, plus a new one that allows you to add items to the Tools menu. You can also provide different icons for your menu items. For example:

browser.menus.create({
  id: "sort-tabs",
  title: "A-Z",
  contexts: ["tools_menu"],
  icons: {
   16: "icon-16-context-menu.png",
  },
});



The windows API now has the ability to read and preface the title of the window object, by passing titlePreface to the window object. This allows extensions to label different windows so they’re easier to distinguish.

The downloads.open API now requires user interaction to be called. This mirrors the Chrome API which also requires user interaction. You can now download a blob created in a background page.

The tabs API has new printing APIs. The tabs.print, tabs.printPreview and tabs.saveAsPDF (not on Mac OS X) methods will bring up the respective print dialogs for the page. The tabs.Tab object now includes the time the tab was lastAccessed.

The webRequests API can now monitor web socket connections (but not the messages)  by specifying ws:// or wss:// in the match pattern. Similarly the match patterns now support moz-extension URLs, however this only applies to the same extension. Importantly a HTTP 302 redirection to a moz-extension page will now work. For example, this was a common use case for extensions that integrated with OAuth.

The pageActions API can now be shown on a per tab basis on Android.

The privacy API gained two new APIs. The privacy.services.passwordSavingEnabled API allows an extension to toggle the preferences that control password saving. The privacy.websites.referrersEnabled API allows an extension to toggle the preferences that control the sending of HTTP Referrer headers.

A new API to control browserSettings has been added with an API to disable the browser’s cache. We’ll use this API for similar settings in the future.

In WebExtensions, we manage the changing of preferences and effects when extensions get uninstalled. This management was applied to chrome_url_overrides. The same management now prevents extensions overriding user changed preferences.

The theming API gained a reset method which can be called after an update to reset Firefox to the default theme.

The proxy API now has the ability to clear out a previously registered proxy.

If you’d like store a large amount of data in indexedDB (something we recommend over storage.local) then you can do so by requesting the unlimitedStorage permission. Requesting this will stop indexedDB prompting the user for permission to store a large amount of data.

The management API has added get and getAll commands. This allows extensions to query existing add-ons to spot any potential conflicts with other content.

Finally, the devtools.panels.elements.onSelectionChanged API landed and extensions that use the developer tools will find that their panels open faster.

Out of process extensions

We first mentioned out of process extensions back in the WebExtensions in Firefox 52 blog post. They’ve been a project that started back in 2016, but they have now been turned on for Windows users in Firefox 56. This is a huge milestone and a lot of work from the team.

This means that all the WebExtensions will run in their own process (that’s one process for all extensions). This has many advantages, but chief among them are  performance, security, and crash handling. For example, a crash in a WebExtension will no longer bring down Firefox. Content scripts from WebExtensions are still handled by the content process.

With the new WebExtensions architecture this change was completed with zero changes by extension developers, a significant improvement over the legacy extension environment.

There are some remaining bugs on Linux and OS X that prevent us from enabling it there, but we hope to enable those in the coming releases.

Along with measuring the performance of out of process, we’ve added in multiple telemetry signals to measure the performance of WebExtensions.  For example, it was recently found that storage.local.set was slow. With some improvements, we’ve seen a significant performance boost from a median of over 200ms down to around 25ms:

These telemetry measures conform to the standard Mozilla telemetry guidelines.

about:debugging

The about:debugging page got some more improvements:

The add-on ID has been added to the page. If there’s a warning about processing the add-on, that will now be shown next to the extension. Perhaps most useful to those working on their first add-on, if an add-on fails to load because of a problem, then no problem—there’s now an easy “retry” button for you to press:

Contributors

Thank you once again to our many contributors for this release, especially our volunteers including: Cameron Kaiser, dw-dev, Giorgio Maone, Swapnesh Kumar Sahoo, Timothy Johnson, Tushar Saini and Tomislav Jovanovic.

Update: improved the quality of the image for context menus and removed the line about “twice as long…”.

Upcoming Changes in Compatibility Features

Firefox 57 is now on the Nightly channel (along with a shiny new logo!). And while it isn’t disabling legacy add-ons just yet, it will soon. There should be no expectation of legacy add-on support on this or later versions. In preparation for Firefox 57, a number of compatibility changes are being implemented on addons.mozilla.org (AMO) to support this transition.

Upcoming Compatibility Changes

  • All legacy add-ons will have strict compatibility set, with a maximum version of 56.*. This is the end of the line for legacy add-on compatibility. They can still be installed on Nightly with some preference changes, but may break due to other changes happening in Firefox.
  • Related to this, you won’t be able to upload legacy add-ons that have a maximum version set higher than 56.*.
  • It will be easier to find older versions of add-ons when the latest one isn’t compatible. Some developers will be submitting ports to the WebExtensions API that depend on very recent API developments, so they may need to set a minimum version of 56.0 or 57.0. That can make it difficult for users of older versions of Firefox to find a compatible version. To address this, compatibility filters on search will be off by default. Also, we will give more prominence to the All Versions page, where older versions of the add-on are available.
  • Add-ons built with WebExtensions APIs will eventually show up higher on search rankings. This is meant to reduce instances of users installing add-ons that will break within a few weeks.

We will be rolling out these changes in the coming weeks.

Add-on compatibility is one of the most complex AMO features, so it’s possible that some things won’t work exactly right at first. If you run into any compatibility issues, please file them here.

Friend of Add-ons: Santosh Viswanatham

Our newest Friend of Add-ons is Santosh Viswanatham! Santosh attended a regional event hosted by Mozilla Rep Srikar Ananthula in 2012 and has been an active leader in the community ever since.  Having previously served as a Firefox Student Ambassador and Regional Ambassador Lead, he is currently a Tech Speaker and a member of the Mozilla Campus Clubs Advisory Committee, where he is helping develop an activity for building extensions for Firefox.

Santosh has brought his considerable enthusiasm for open source software to the add-ons community. Earlier this year, he served a six-month term as a member of the Featured Add-ons Advisory Board, where he helped nominate and select extensions to be featured on addons.mozilla.org each month. Additionally, Santosh hosted a hackathon in Hyderabad, India, where 100 developers spent the night creating more than 20 extensions.

When asked to describe his experience contributing to Mozilla, Santosh says:

“It has been a wonderful opportunity to work with like-minded incredible people. Contributing to Mozilla gave me an opportunity to explore myself and stretched my limits working around super cool technologies. I learned tons of things about technology and communities, improved my skill set, received global exposure, and made friends for a lifetime by contributing to Mozilla.”

In his free time, Santosh enjoys dining out at roadside eateries, spending time with friends, and watching TV shows and movies.

Congratulations, Santosh, and thank you for all of contributions!

Are you a contributor to the add-ons community or know of someone who should be recognized? Please be sure to add them to our Recognition Wiki!

Extension Examples: See the APIs in Action

In the past year, we’ve added a tremendous amount of add-on documentation to MDN Web Docs. One resource we’ve spent time building out is the Extension Examples repository on GitHub, where you can see sample extension code using various APIs. This is helpful for seeing how WebExtensions APIs are used in practice, and it is especially helpful for people just getting started building extensions.

To make the example extensions easier to understand, there is a short README page for each example. There is also a page on MDN Web Docs that lists the JavaScript APIs used in each example.

With the work the Firefox Developer Tools team has completed for add-on developers, it is easier to temporarily install extensions in Firefox for debugging purposes. Feel free to try it out with the example extensions.

As we ramp up our efforts for Firefox 57, expect more documentation and examples to be available on MDN Web Docs and our GitHub repository. There are currently 47 example extensions, and you can help grow it by following these instructions.

Let us know in the comments if you find these examples useful, or contact us using these methods. We encourage you to contribute your own examples as well!

Thank you to all who have contributed to growing the repository.