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:

image00

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.

Uploads

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 (//).

Translations

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.

Compatibility

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.

Recognition

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.

Engineering

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.

Add-on Compatibility for Firefox 49

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

General

XPCOM and Modules

Let me know in the comments if there’s anything missing or incorrect on these lists. If your add-on breaks on Firefox 49, 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 48.

Friend of Add-ons: Yuki Hiroshi

piro-photoPlease meet our newest Friend of Add-ons: Yuki “Piro” Hiroshi. A longtime add-on developer with 37 extensions and counting (he’s most proud of Tree Style Tab and Second Search), Hiroshi also recently filed more than two dozen high-impact WebExensions bugs.

Hiroshi recently recounted his experience porting one of his XUL add-ons to WebExtensions in the hopes that he could help support fellow add-on developers through the transition. He likens XUL to an “experimental laboratory” that over the past decade allowed us to explore the possibilities of a customized web browser. But now, Hiroshi says, we need to “go for better security and stability” and embrace forward-thinking API’s that will cater to building richer user experiences.

While add-ons technology is evolving, Hiroshi’s motivation to create remains the same. “It’s an emotional reason,” he says, which took root when he first discovered the power of a Gecko engine that allowed him to transform himself from being a mere hobbyist to a true developer. “Mozilla is a symbol of liberty for me,” Hiroshi explains. “It’s one of the legends of the early days of the web.”

When he’s not authoring add-ons, Hiroshi enjoys reading science fiction and manga. A recent favorite is The Hyakumanjo Labyrinth, a “bizarre adventure story” that takes place on an infinity field beyond space and time within an old Japanese apartment building.

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