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!

1 response

  1. Ken Saunders wrote on :

    I really like these types of instructive articles especially when they include (links to) working examples.

    I prefer to learn hands on and/or by example after reading a summary, so sample add-ons and code snippets are really appreciated.
    Please keep them coming. Especially for WebExtensions.

    “If you don’t recognize the dark theme in the screenshots, it’s because I’m using Firefox Developer Edition…”
    For what it’s worth for your readers.
    Developer Edition theme enabler
    “Enables the DevEdition theme on beta or release”
    https://addons.mozilla.org/firefox/addon/devedition-theme-enabler

    Thanks for the article.