Add-ons Update – 2016/11

Here’s the state of the add-ons world this month.

The Review Queues

In the past month, 1,732 listed add-on submissions were reviewed:

  • 1,340 (77%) were reviewed in fewer than 5 days.
  • 130 (8%) were reviewed between 5 and 10 days.
  • 262 (15%) were reviewed after more than 10 days.

There are 220 listed add-ons awaiting review.

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.

Compatibility

The compatibility blog post for Firefox 51 is up, and the bulk validation should be run in the coming weeks. It’s worth pointing out that the Firefox 50 cycle will be twice as long, so 51 won’t be released until January 24th, 2017.

Multiprocess Firefox is now enabled for users without add-ons, and add-ons will be gradually phased in, so make sure you’ve tested your add-on and either use WebExtensions or set the multiprocess compatible flag in your add-on manifest.

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.

Recognition

We would like to thank André Bargull, Meet Mangukiya, Jostein Kjønigsen, euleram, saintsebastian, Rob Wu , Andrew Terranova, Prasanth P, and Venkat Ganesan for their recent contributions to the add-ons world. You can read more about their work in our recognition page.

More ways to contribute to WebExtensions

Since the transition to WebExtensions began, people have contributed bug fixes, APIs, documentation, and tons of valuable feedback. Contributors have given talks about WebExtensions at events all over the world, and developers have taken on the sometimes immense task of migrating their add-ons. It’s been a community effort, and now there are two more ways to contribute to WebExtensions, by participating in the development of APIs.

WebExtensions Experiments: tinker with APIs without having to build Firefox

Previously, if you were a developer who wanted to write WebExtensions APIs, you would have to be familiar with Mozilla infrastructure, like building mozilla-central, working with Bugzilla, and the try server. With WebExtensions Experiments, people who want to prototype APIs for landing in Firefox or use them on Nightly or Developer Edition can do so without having to build Firefox. Experiments work by allowing WebExtensions APIs to be written in another extension, so if you can write an extension, you can prototype a new API.

Help plan and prioritize APIs

Anyone can request an API by filing a bug, and now there is a public triage of these bugs every other week to decide which ones benefit the most developers and users, and support the WebExtensions vision of a safer, cross-browser standard for add-ons. One goal of the triage, which anyone interested is welcome to join, is to provide details and considerations for each prioritized API, making it easier for people to contribute to them. The more complex APIs are also posted on a public Trello board for better tracking.

Join us

If you want to help drive WebExtensions forward, or simply listen in on discussions, please subscribe to the dev-addons@mozilla.org mailing list.

November’s Featured Add-ons

Firefox Logo on blue background

Pick of the Month: Blur

by Abine
Secure all of your personal information online—passwords, shopping accounts and more, plus tracking protection.

“It’s almost impossible to keep up with the number of passwords that we must have for various sites. What makes it more difficult, is making sure each password varies. Blur makes this daunting task a thing of the past. It’s so simple to add/save new passwords.”

Featured: Instant Translate

by Twopeople Software
Translate words and phrases in 100+ languages, use text-to-speech, and easily browse your history of previous translations.

“Big + for having a history of translations. Very useful and simple to use.”

Featured: Privacy Badger

by EFF Technologists
Automatically block sneaky spyware in ads and invisible trackers as you navigate the Web.

“This doesn’t block ads but limits/stops unwanted sites tracking your every click. A must have!”

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, and we just so happen to be looking for new applicants right now! 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!

Apply to Join the AMO Feature Board

Do you like making people happy? Great add-ons make people happy.

Do you like making people happy? Great add-ons make people happy.

Are you a big fan of add-ons? Do you appreciate great functionality? Can you spot stellar design? And do you want to make a huge impact for AMO? Then check this out…

Twice a year we invite a handful of new contributors to become part of AMO’s Feature Board. These folks help identify AMO’s new monthly featured add-ons for six months. Millions of users look to AMO’s featured content to find the best add-ons. Downloads increase dramatically for the add-ons selected.

Now the time has come to assemble a new board for the months January – June.

Anyone from the add-ons community is welcome to apply: power users, theme designers, developers, and evangelists. Priority will be given to applicants who have not served on the board before, followed by those from previous boards, and finally from the outgoing board. This page provides more information on the duties of a board member. To be considered, please email us at amo-featured@mozilla.org with your name, and tell us how you’re involved with AMO. The deadline is Friday, November 11, 2016 at 23:59 PDT. The new board will be announced shortly thereafter.

We look forward to hearing from you!

Add-ons Update – 2016/10

Here’s the state of the add-ons world this month.

The Review Queues

In the past month, 1,755 listed add-on submissions were reviewed:

  • 1,438 (82%) were reviewed in fewer than 5 days.
  • 119 (7%) were reviewed between 5 and 10 days.
  • 198 (11%) were reviewed after more than 10 days.

There are 223 listed add-ons awaiting review.

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.

Compatibility

The compatibility blog post for Firefox 50 is up, and the bulk validation was run recently. The compatibility blog post for Firefox 51 has published yesterday. It’s worth pointing out that the Firefox 50 cycle will be twice as long, so 51 won’t be released until January 24th, 2017.

Multiprocess Firefox is now enabled for users without add-ons, and add-ons will be gradually phased in, so make sure you’ve tested your add-on and either use WebExtensions or set the multiprocess compatible flag in your add-on manifest.

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.

Recognition

We would like to thank Atique Ahmed Ziad, Surya Prashanth, freaktechnik, shubheksha, bjdixon, zombie, berraknil, Krizzu, rackstar17, paenglab, and Trishul Goel (long list!) for their recent contributions to the add-ons world. You can read more about their work in our recognition page.

Add-on Compatibility for Firefox 51

Firefox 51 will be released on January 24th. Note that the scheduled release on December 13th is a point release, not a major release, hence the much longer cycle. Here’s the list of changes that went into this version that can affect add-on compatibility. There is more information available in Firefox 51 for Developers, so you should also give it a look.

General

XPCOM and Modules

New!

  • Embedded WebExtensions. You can now embed a WebExtension into any restartless add-on, allowing you to gradually migrate your code to the new platform, or transition any data you store to a format that works with WebExtensions.
  • WebExtension Experiments. This is a mechanism that allows us (and you!) to prototype new WebExtensions APIs.

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

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

Friend of Add-ons: Atique Ahmed Ziad

Please meet our newest Friend of Add-ons: Atique Ahmed Ziad, who in September alone closed 14 AMO bugs!

Atique is primarily interested in front-end work. His recent contributions mostly focused on RTL language bugs, however it was this complex error messaging bug that proved the most challenging because it forced Atique to grapple with complex code.

Beyond crushing bugs, Atique also helps organize Activate campaigns.

When he’s not busy being a tireless champion for the open Web, Atique likes to unwind by taking in a good movie or playing video games; and while he’s one of the nicest guys you’ll ever meet, you’ll want to avoid him in the virtual settings of Grand Theft Auto and Call of Duty.

On behalf of the AMO staff and community, thank you for all of your great work, Atique!

Do you contribute to AMO in some way? If so, don’t forget to add your contributions to our Recognition page!

October 2016 Featured Add-ons

Firefox Logo on blue background

Pick of the Month: MailtoWebmails

by Noitidart
Now you can easily customize which Webmail client you want to use whenever you click a “mailto:” link, instead of being pushed to your default desktop email. Get completely set up in just a few simple steps.

“I searched repeatedly for a way to change from Gmail to inbox—this works like a treat.”

Featured: Messenger & Notifier for Facebook™

by glin, by Elen Norphen
Access Messenger right from the Firefox toolbar, and instantly receive notifications when you have inbound messages.

“Finally I can reply to messages without being distracted by the news feed! Thank you very much!”

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!

WebExtensions in Firefox 51

Firefox 51 landed in Developer Edition this week, so we have another update on WebExtensions for you. In this update, we’re making it easier for you to port your existing add-ons to WebExtensions. In addition to being fully compatible with multiprocess Firefox, WebExtensions are becoming the standard for add-on development.

Embedded WebExtensions

In Firefox Developer Edition, you can now embed a WebExtensions add-on inside an existing SDK or bootstrapped add-on.

This is especially useful to developers of SDK or bootstrapped add-ons who want to start migrating to WebExtensions and take advantage of new APIs like Native Messaging, but can’t fully migrate yet. It’s also useful for developers who want to complete data migration towards WebExtensions, and who want to take parts of their add-on that are not compatible with multiprocess Firefox and make them compatible.

For more documentation on this, please head over to MDN or check out some examples.

If you need help porting to WebExtensions, please start with the compatibility checker, and check out these resources.

Manifest Change

Because of confusion around the use of strict_min_version in WebExtensions manifests, we’ve prevented the use of * in strict_min_version, for example 48.* is no longer valid. If you upload an add-on to addons.mozilla.org we’ll warn you of that fact.

API Changes

The clipboardWrite permission is now enabled which removes the need to be in a user gesture. This is usable from extension tabs, popups and content scripts.

When a WebExtensions add-on is uninstalled, any local storage is now cleared. If you’d like to persist data across an uninstall then you can use the upcoming sync storage.

The management API now supports the uninstallSelf and getSelf methods. The idle.queryState API has been updated to accurately reflect the state, previously it always returned the value “idle”.

In the webRequest API, onBeforeRequest is now supported in Firefox Nightly and Developer Edition. There are some platform changes that are required to get that to land in a Release version of Firefox.

Developers have been testing out Native messaging and a couple of bugs were filed and fixed on that. New, more detailed, documentation has been written. One of the useful pieces of feedback involved the performance of the round-trip time, and that has now improved.

There has been a few improvements to the appearance of popup windows including the popup arrow, the corners of the popup and reducing flicker on the animation. Here’s a before and after:

popup-before

popup-after

Out of process extensions

Now that the majority of the work multi process Firefox has been completed, we are looking ahead to the many improvements it can bring. One of them is allowing WebExtensions to be run in a separate process. This process-sandboxing of add-ons will bring clear performance and security benefits.

But before we can do that, there is quite a bit of work that needs to be done. The main tracking bug lists some of these tasks. There is also a video of Rob Wu presenting the work he has done on this. There currently isn’t a timeline for when this will be landed, but the work is progressing.

Recognition

We’d also like to give a thank you to four new contributors to WebExtensions, who’ve helped with this release. Thanks to sj, Jorg K, fiveNinePlusR and Tomislav.

Update: link to Robs presentation fixed.

How Video DownloadHelper Became Compatible with Multiprocess Firefox

Today’s post comes from Michel Gutierrez (mig), the developer of Video DownloadHelper, among other add-ons. He shares his story about the process of modernizing his XUL add-on to make it compatible with multiprocess Firefox (e10s).

***

Video DownloadHelper (VDH) is an add-on that extracts videos and image files from the Internet and saves them to your hard drive. As you surf the Web, VDH will show you a menu of download options when it detects something it can save for you.

It was first released in July 2006, when Firefox was on version 1.5. At the time, both the main add-on code and DOM window content were running in the same process. This was helpful because video URLs could easily be extracted from the window content by the add-on. The Smart Naming feature was also able to extract video names from the Web page.

When multiprocess Firefox architecture was first discussed, it was immediately clear that VDH needed a full rewrite with a brand new architecture. In multiprocess Firefox, DOM content for webpages run in a separate process, which means required asynchronous communication with the add-on code would increase significantly. It wasn’t possible to simply make adaptations to the existing code and architecture because it would make the code hard to read and unmaintainable.

The Migration

After some consideration, we decided to update the add-on using SDK APIs. Here were our requirements:

  • Code running in the content process needed to run separately from code running in Javascript modules and the main process. Communication must occur via message passing.
  • Preferences needed to be available in the content process, as there are many adjustable parameters that affect the user interface.
  • Localization of HTML pages within the content script should be as easy as possible.

In VDH, the choice was made to handle all of these requirements using the same Client-Server architecture commonly used in regular Web applications: the components that have access to the preferences, localization, and data storage APIs (running in the main process) serve this data to the UI components and the components injected into the page (running in the content process), through the messaging API provided by the SDK.

Limitations

Migrating to the SDK enabled us to become compatible with multiprocess Firefox, but it wasn’t a perfect solution. Low-level SDK APIs, which aren’t guaranteed to work with e10s or stay compatible with future versions of Firefox, were required to implement anything more than simple features. Also, an increased amount of communication between processes is required even for seemingly simple interactions.

  • Resizing content panels can only occur in the background process, but only the content process knows what the dimensions should be. This gets more complicated when the size dynamically changes or depends on various parameters.
  • Critical features like monitoring network traffic or launching external programs in VDH requires low-level APIs.
  • Capturing tab thumbnails from the Add-on SDK API does not work in e10s mode. This feature had to be reimplemented in the add-on using a framescript.
  • When intercepting network responses, the Add-on SDK does not decode compressed responses.
  • The SDK provides no easy means to determine if e10s is enabled or not, which would be useful as long as glitches remain where the add-on has to act differently.

Future Direction

Regardless of the limitations posed, making VDH compatible to multiprocess Firefox was a great success. Taking the time to rewrite the add-on also improved the general architecture and prepared it for changes needed for WebExtensions. The first e10s-compatible version of VDH is version 5.0.1 and had been available since March 2015.

Looking forward, the next big challenge is making VDH compatible with WebExtensions. We considered migrating directly to WebExtensions, but the legacy and low-level SDK APIs used in VDH could not be replaced at the time without compromising the add-on’s features.

To fully complete the transition to WebExtensions, additional APIs may need to be created. As an extension developer we’ve found it helpful to work with Mozilla to define those APIs, and design them in a way that is general enough for them to be useful in many other types of add-ons.

A note from the add-ons team: resources for migrating your add-ons to WebExtensions can be found here.