Tinkering with WebExtensions

Jorge Villalobos

2

I’ve been writing about WebExtensions development on my blog. I’ve kept those posts over there because they’re short one-offs that I think would be too noisy for this blog and its wide audience.

That’s why I’m giving you this quick overview of what I’ve been writing so you can give them a closer look if you’re interested. The first two posts might interest you if you’re an add-on developer curious about WebExtensions. The second two are more meta, and touch on documentation, code review, and how we’re trying to shape the developer experience.

Let us know if there’s any topic around WebExtensions or other add-on development you want us to cover.

Add-ons Update – Week of 2016/03/30

Jorge Villalobos

1

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

  • 981 (94%) were reviewed in fewer than 5 days.
  • 37 (4%) were reviewed between 5 and 10 days.
  • 28 (3%) were reviewed after more than 10 days.

There are 73 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 get invited to Mozilla events and earn cool gear with their work. Visit our wiki page for more information.

Compatibility Communications

Most of you should have received an email from us about the future compatibility of your add-ons. You can use the compatibility tool to enter your add-on ID and get some info on what we think is the best path forward for your add-on.

To ensure long-term compatibility, we suggest you start looking into WebExtensions, or use the Add-ons SDK and try to stick to the high-level APIs. There are many XUL add-ons that require APIs that aren’t available in either of these options, which is why we’re also asking you to fill out this survey, so we know which APIs we should look into adding to WebExtensions.

Firefox 46 Compatibility

The compatibility blog post is up. The bulk validation was run yesterday.

Firefox 47 Compatibility

The compatibility blog post for 47 is coming 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.

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 46.

Electrolysis

Electrolysis, also known as e10s, is the next major compatibility change coming to Firefox. 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!

Add-on Signing Enforcement In Firefox 46 for Android

Kev Needham

13

As part of the Extension Signing initiative, signing enforcement will be enabled by default on Firefox 46 for Android. All Firefox for Android extensions on addons.mozilla.org have been signed, and developers who self-host add-ons for Android should ensure those add-ons are signed prior to April 12th, 2016.

Extension signing enforcement can be disabled using the preference outlined in the FAQ, and this preference will be removed in a future release.

More information on Extension Signing is available on the Mozilla Wiki, and information on the change to Firefox for Android can be found on Bugzilla under Bug 1244329.

Advantages of WebExtensions for Developers

Potch

10

First, a Little Backstory

Presently, Firefox supports two main kinds of add-ons. First were XUL or XPCOM add-ons, which interface directly with the browser’s internals. They are fabulously powerful, as powerful as the browser itself. However, with that power comes security risk and the likelihood that extensions will break as the browser changes.

The Add-on SDK was introduced to provide a stable abstraction API above browser internals to reduce extension compatibility issues between versions of Firefox and make it easier to review extensions for security. As the browser evolved, however, it became clear that we needed something even more robust to take us into the future.

WebExtensions is the new API for building add-ons in Firefox. It seeks to unify the extension APIs and architecture with those of other browsers in the name of interoperability and modern architecture.

The introduction of WebExtensions isn’t an arbitrary change—it stands to improve the stability and security of Firefox for users. It also has a number of advantages for developers.

Cross-Browser Interoperability

Potentially the most impactful aspect of WebExtensions is that it adopts the extension architecture used by browsers built on top of Chromium, notably Chrome and Opera. Mozilla is committed to implementing a large number of the individual APIs presently available to Chrome extensions. This means that it’s possible to have one codebase for an extension that will work in Firefox, Chrome, and Opera with a minimal amount of browser-specific code.

More than Chrome Parity

While our initial API priorities are focused on allowing Chrome extensions to interoperate with Firefox, we plan to competitively and actively expand the API capabilities of WebExtensions. While we anticipate the vast majority of Firefox Add-ons can be ported to WebExtensions, if you need access to browser components not presently exposed, the Add-on SDK is still available. If your add-on or one you use and love is doing something that is not possible with Chrome extensions or the Add-on SDK, please fill out this survey to help us prioritize new APIs.

Common Functionality is Easier

A large number of browser extensions take the form of content scripts, where Javascript is executed against certain (or in some cases all) web pages. WebExtensions optimizes for this case by allowing developers to reduce these types of extensions to 2 files: the script, and a manifest describing the extension and on which pages it should be injected.

Future-Proofing your Work

XPCOM/XUL add-ons are notoriously brittle, breaking whenever browser internals change. The Add-on SDK provides a more stable API surface, but has many synchronous APIs that cross between add-on contexts and web page contents. Mozilla is committed to moving Firefox to a multi-process architecture this year to increase security and stability (read more here), which will break many of these synchronous APIs. WebExtensions APIs are being implemented from the ground-up to be ready for a multi-process Firefox, using asynchronous message passing and event-driven interfaces to enable extensions to communicate with the browser and web pages.

More Secure Extensions

Because extensions built with the Add-on SDK can request XPCOM privileges, they could still introduce unintentional security and stability issues into Firefox. Even add-ons written by well-meaning developers can accidentally introduce vulnerabilities that could allow malicious code to execute with the full privileges of the browser. WebExtensions uses its manifest.json to mitigate this by requiring add-on authors to declare up front which permissions their code will need to operate. Unlike the Add-on SDK, WebExtensions does not allow arbitrary XUL/XPCOM access, so even insecure/vulnerable code is limited to its whitelisted subset of functionality. This vastly reduces the vulnerability surface of a WebExtension, leading to faster review times and a more stable browser.

The Path Forward

We know WebExtensions is a big change, and we’re committed to helping developers prepare and adapt as we roll it out. Initial support for WebExtensions is coming in Firefox 48, and add-ons built with WebExtensions can already be submitted to addons.mozilla.org. The time is now to start experimenting and porting your add-ons! Here are some links to help you get started:

  • If you’re an existing add-on author, check out this collection of resources on migrating your add-on to WebExtensions.
  • If you’re the author of a Chrome extension, we have a short guide on adding Firefox support to your existing codebase.
  • You can also check out this wiki to see more ways to participate in the evolution of WebExtensions.

WebExtensions in Firefox 47

Andy McKay

4

We last updated you on our progress with WebExtensions when Firefox 46 landed in Developer Edition (Aurora), and today we have an update for Firefox 47, which landed in Developer Edition last week.

While WebExtensions will remain in a beta state in Firefox 47, we’ve made lots of progress, with 81 bugs closed since the last update. As of this update, we are still on track for a milestone release in Firefox 48 when it hits Developer Edition.

There’s a new way for you to get involved! Tell us which APIs you’d like support for by filling out this survey, to help us better prioritize them. We have also created a wiki page filled with resources to support developers through all the changes coming in the add-ons world.

APIs Implemented

Adding keyboard shortcuts that trigger actions in your extension arrived with the partial implementation of commands. This allows developers to map key presses from the manifest to actions in your add-on.

With the partial implementation of downloads you can download files from your add-on and get updates of the download progress. You can also search through the existing downloads using the search API.

Several additions and changes in webRequest have been included in Firefox 47. These prelude even bigger news for add-ons that focus on security and privacy to work perform the sort of network inspection needed to do their job. More details on these changes are covered in Giorgio’s blog post.

Also completed is the i18n API and we are getting closer to completing the bookmarks API.

More of the tabs API have been completed, including:

Several improvements have been made to the windows API, including :

  • Added support for creating a new window from an existing tab, popup-type windows
  • Querying and changing a windows’ minimized, maximized and fullscreen state.

All asynchronous methods which accept a callback function will now return a Promise if no callback is passed. These promises resolve at the same time a callback would normally be called, and reject with the value of lastError in cases where that would otherwise be set. Additionally, onMessage listeners may now return a Promise object if they wish to send a reply. When the promise resolves, its resolution value will be returned to the sender.

WebExtension manifests now support a “creator” property, which is displayed in the Add-on Manager, to indicate the author of the add-on. Additionally, manifests are now fully type-checked at startup, and any type errors or unexpected properties are reported to the Browser Console for inspection.

For the full list of API changes, please see the bug list.

Command line tool

A new command line tool is being build for WebExtensions, called “web-ext” will allow you to run, test and sign add-ons easily from the command line. For example to run your add-on in a new profile, from your add-on, just call: web-ext run.

This command line utility is in its early days, but you can follow along with web-ext development on github.

New examples

We’ve been preparing examples of our APIs on github. In the last few weeks we’ve added two more examples:

  • bookmark-it: an add-on that toggles a bookmark for the currently active tab.
  • tabs-tabs-tabs: an add-on that demonstrates some of the tabs APIs available (currently move, duplicate, reload and remove)

There are currently ten example add-ons available in the repository. All of them can be installed easily by cloning the repository locally and then installing temporarily through about:debugging.
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, please join us on our mailing list or at one of our public meetings. You can also check out this wiki to see more ways to participate in the evolution of WebExtensions.

Developer support for changes in add-on development

Amy Tsay

4

As you may have heard, there are a lot of changes coming up for add-on development. By the end of 2017, we will transition to WebExtensions as the standard for creating add-ons. Over the same period of time, existing methods for add-on development such as XUL/XPCOM will be deprecated. Multi-process Firefox (aka Electrolysis, or e10s) is also rolling out, which means some developers will have to update their add-on more than once. All this on the heels of add-on signing.

In the past few weeks, we’ve been gathering all the information and resources we could to help developers navigate the upcoming changes. We’re also lining up new content so we can continue to keep everyone informed and supported during this adjustment period.

Everything we’ve collected so far is here. A few notable pieces of information you’ll find:

  • A lookup tool you can use to see if your add-on will be impacted, and if so what the recommended migration path is.
  • A survey you can use to tell us which WebExtension APIs you need, so we can better prioritize them.
  • A timeline of changes that includes dates to the best of our knowledge. This is a working doc and will be updated as we learn of new information.
  • A calendar you can add to see upcoming meetings, blog posts, and office hours. We will also be adding release milestones to the calendar in the coming weeks.

Blog posts and other documentation related to the transition are added here as they’re created. We have more content queued up, and as you can see we could use even more. If you’re interested in writing about your experience creating a WebExtension add-on, or becoming e10s compatible, or anything else that others might find relevant, please sign up here.

We’ll keep releasing information on the wiki as they become available. If you have ideas or would like to pitch in, please reach out to us. We’re here to help.

AMO updates on version number re-use

Andrew Williamson

5

With recent changes, addons.mozilla.org (AMO) now more strictly enforces our rule requiring version numbers for add-ons to be unique.

Previously, the website allowed some edge cases where if a version was deleted or disabled before we reviewed it, a new version with the same version number could be uploaded.  This caused issues with our CDN where the old xpi was cached. The hash (used for verification) could be wrong so the install would fail, and any users who installed the old xpi would fail to get the update to the ‘real’ version.

Now, once a version has been uploaded to AMO with a version number, you will be unable to use it again. Deleting or disabling the version won’t release the version number for re-use.  This restriction applies to add-ons that are uploaded for signing and external listing as well as ones listed on AMO.

We’re aware this will cause some irritation to developers when they try to upload again, and that perfect version “10.0.0.0” may be lost due to a hasty upload, but we believe the user benefits in this case outweigh the extra restriction on developers.

Add-ons Update – Week of 2016/03/09

Jorge Villalobos

2

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

  • 1007 (95%) were reviewed in less than 5 days.
  • 26 (2%) were reviewed between 5 and 10 days.
  • 32 (3%) were reviewed after more than 10 days.

There are 102 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 get invited to Mozilla events and earn cool gear with their work. Visit our wiki page for more information.

Firefox Accounts

Firefox Accounts is now live on AMO. Next time you log in, you’ll be prompted to migrate your account. If you have any problems with this process, please post in the forum thread.

Firefox 45 Compatibility

This compatibility blog post is up. The bulk compatibility validation was run last week.

Firefox 46 Compatibility

The compatibility blog post is up. We expect to run the bulk validation in a couple of 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 46 (updated from the previous deadline of Firefox 44).

Electrolysis

Electrolysis, also known as e10s, is the next major compatibility change coming to Firefox. 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!

WebExtensions

We’re working on the new WebExtensions API, and we recommend that you start looking into it for your add-ons. You can track progress of its development in http://www.arewewebextensionsyet.com/.

Your Story Goes Here

Scott DeVaney

2

011How do add-ons enhance your browsing experience in uniquely productive or creative ways?

We’re planning to run a series of stories on this blog on how people use add-ons to make Firefox their own. Maybe you’re one of these folks? If so, we want to speak with you!

The stories can be about anything… students who use calculator, language, or other education content… professionals who use add-ons to help run their businesses… artists leveraging the power of creativity tools… serious online shoppers using add-ons to scour the web for great deals… so many possibilities!

If you’d like to tell your story, please email editor@mozilla.com with “my story” in the subject line and tell us a bit about the add-ons you use and why.

Breakthroughs in the add-on review queues

Jorge Villalobos

3

The last few months have been dense with big changes in the add-ons world. Just reading this blog and looking at all the new faces and posts should give you a good idea. Today I’d like to show you how these changes have affected the add-on review queues and what you can expect for the future.

These charts show the state of the review queues on a weekly basis, starting on Q4 last year:

Full review queue Preliminary review queue Update queue

The green area represents add-ons that have been waiting under 5 days, yellow between 5 and 10 days, and red over 10 days.

As you can see, we were doing pretty poorly in late 2015. We only had one admin reviewer, Andreas Wagner, whose attention was almost entirely focused on reviewing unlisted add-ons (not included in the charts). We already had a significant backlog of add-ons awaiting admin review, and during this time it got a lot worse. We were looking for new admin reviewers we could get on board as contractors, but most of our attention was focused on extension signing.

Turning the tide

A few things happened that helped us get the review queues under control:

  • We stopped gating unlisted add-on signing by review. This freed Andreas’s time so he could go back to review listed add-ons.
  • Our team (finally!) grew. We now have Philipp Kewisch as our second full time admin reviewer and Noitidart helping part time also as an admin. Other areas of the team also got help, like the AMO dev team and editorial, all of which has afforded us much-needed breathing room and focus.
  • Our volunteer team also ramped up their efforts and kept up with the increased submission rate. During the first few weeks of the year, they averaged over 500 reviews per week! This is an amazing feat, especially to those of us who know about the pains of code review.

The review queues are now almost entirely in the green, which is fantastic (in fact, we’re all green in today’s report). However, it’s reasonable to have some skepticism, since we’ve been here before. We rely on a couple of very active volunteers who do the bulk of the reviews. And we will need to turn more of our attention to unlisted submissions soon (though not to the same extent as before).

Keeping it that way

So, what are we doing to maintain wait times that developers can rely on?

First, we have the staff additions I mentioned earlier. Having a stable admin team contributes greatly because we have a higher baseline even when volunteer activity drops. We also have another part-time opening that we will try to fill soon.

We’ve made some changes to the reviewer tools to encourage more participation from less-active reviewers. The review team has grown significantly in the past couple of months, and we receive new applications all the time. Are you interested in joining us? Please apply!

Finally, I think we’re past the big wave of submissions that happened due to the introduction of extension signing. But we do have a stable and steady increase in developer activity (which is good!).

We’d like to thank the add-on developer community for their immense patience during this time. We know it’s been rough and we’re very grateful that you stuck with us. We’ll keep working hard to make sure this becomes the standard.