Improving the Add-ons Linter

For the last five years, Mozilla has participated in the Outreachy program to provide three-month internships for people from groups traditionally underrepresented in tech. From December 2017 – March 2018, interns Ravneet Kaur and Natalia Milavanova worked under the guidance of Christopher Grebs and Luca Greco to improve the add-ons linter.

The add-ons linter is a tool that warns of potential problems within an extension’s code. Developers can use the web-ext command line tool to run the linter locally to check for potential issues during development, and addons.mozilla.org (AMO) uses it to validate an extension during the submission process.

Ravneet’s internship project was to land a localization feature to the add-ons linter. By offering the option to see errors and warnings in multiple languages, the linter can be more accessible to add-on developers who prefer to work with non-English languages. Ravneet successfully adapted Pontoon’s localization method for the add-ons linter and extracted about 19,000 lines of code in the process.

Outreachy internships are a great way to gain real-world experience working with distributed teams and grow software development skills. “This project was the first time I was introduced to the idea of bundling code using technologies like webpack,” Ravneet says. “After going through its documentation and reading blog posts about it, I was fascinated about the idea of bundling code together and building small, minimalistic projects in production, while having a wide variety of maintainable files and folders in the project’s source.”

Natalia tackled a different challenge: improve the linter’s validation by rewriting a large chunk of the code and test suite into async functions. For a long time, the linter’s code had been cumbersome to work with. After refactoring the code, Natalia removed approximately 3% of the code. Luca notes, “Thanks to Natalia’s hard work on this this project, our ability to debug and handle errors in the add-ons linter has been greatly improved. It’s now easier to read and understand the sources, and prepare for the changes that are coming next.”

Thank you for all of your contributions, Natalia and Ravneet! We look forward to seeing your future accomplishments.

If you’re interested in learning more about Outreachy, please visit their website. While you’re at it, check out our own Outreachy alum Shubheksha Jalan’s blog post about her experience applying to the program.

Enter the Firefox Quantum Extensions Challenge

Firefox users love using extensions to personalize their browsing experience. Now, it’s easier than ever for developers with working knowledge of JavaScript, HTML, and CSS to create extensions for Firefox using the WebExtensions API. New and improved WebExtensions APIs land with each new Firefox release, giving developers the freedom to create new features and fine-tune their extensions.

You’re invited  to use your skill, savvy, and creativity to create great new extensions for the Firefox Quantum Extensions Challenge. Between March 15 and April 15, 2018, use Firefox Developer Edition to create extensions that make full use of available WebExtensions APIs for one of the prize categories. (Legacy extensions that have been updated to WebExtensions APIs, or Chrome extensions that have been ported to Firefox on or after January 1, 2018, are also eligible for this challenge.)

A panel of judges will select three to four finalists in each category, and the community will be invited to vote for the winners. We’ll announce the winners with the release of Firefox 60 in May 2018. Winners in each category will receive an iPad Pro and promotion of their extensions to Firefox users. Runners-up will receive a $250 USD Amazon gift card.

Ready to get started? Visit the challenge site for more information (including the official rules) and download Firefox Developer Edition.

Winners will be notified by the end of April 2018 and will be announced with the release of Firefox 60 in May 2018.

Good luck!

Theme API Update

This article is written by Michael de Boer, Mozilla Engineering Manager working on the Firefox Frontend team. Mike has been actively involved in themes for a long time and is excited to share the improvements coming to the WebExtensions Theme API.

Last spring we announced our plans to improve themes in Firefox and today I’d like to share our progress and what you can expect in the next few releases!

We started off with laying the groundwork to get a new type of Theme supported; a new ‘theme’ WebExtension namespace was created and we made the Addon Manager aware of WebExtension Themes.

Our first milestone was to completely support the LightWeight Theme (LWT) features, because they’re so simple. This way we had our first new-style themes that are able to change the background image, background color and foreground text color working very quickly. We continued to implement more properties on top of this solid base and are moving toward Chrome compatibility at a good pace.

If you’ve created an extension before, writing your new Theme will be a walk in the park; you can use about:debugging and an extensive toolbox to load up and inspect your manifest-based theme or WebExtension that uses the ‘theme’ JavaScript API and has obtained the ‘theme’ permission.

What you can use today

Since Firefox 55, extension developers have been able to create extensions that can request permission to change the theme that’s currently active and use a number of JavaScript APIs provided by the `browser.theme` namespace.

We fondly call them ‘dynamic themes’, because you can mix and match WebExtension APIs to create wholly unique browser experiences that may reactively update parts of the browser theme.

In Firefox Quantum 57 you can use the following methods:

  • theme.update([windowId]), with which you can update the browser’s’ theme and optionally do that only for a specific window.
  • theme.reset([windowId]), which removes any theme updates made in a call to `theme.update()`. The optional windowId argument allows you to reset a specific window.

And in Firefox 58 you can use these:

As you might have noticed, the theme.update() method is where the magic happens. But it only does something pretty when you feed it a bag of properties that you want it to change.

These properties are defined in the schema and the current set is:

  • images
    • additional_backgrounds: This is a list (JavaScript Array) of image URLs that will be used as the background of a browser window. Each image will be tiled relative to its predecessor.
    • headerURL: Some of you might recognise this property from LWTs; it may be used to set the topmost background image of a browser window.
    • theme_frame: Alias for the ‘headerURL’ property, which is there for compatibility with Chrome themes.
  • colors
    • accentcolor: Use this property to change the background color of a browser window. Usually, this will be set to look pretty next to the ‘headerURL’ you provide. This is also a property that comes from LWTs.
    • tab_background_text: Alias for the ‘textcolor’ property, providing compatibility with Chrome Themes. (Since Firefox 59.)
    • bookmark_text: Alias for the ‘toolbartext’ property, providing compatibility with Chrome themes. (Since Firefox 58.)
    • frame: Alias for the ‘accentcolor’ property, providing compatibility with Chrome themes.
    • tab_text: Alias for the ‘textcolor’ property, providing compatibility with Chrome themes.
    • textcolor: Use this property to change the foreground color of a browser window and is used for the tab titles, for example. This is also a property the comes from LWTs.
    • toolbar: Change the background color of browser toolbars using this property. This property is also supported by Chrome themes.
    • toolbar_text: And this property can be used to change the foreground color inside browser toolbars, like button captions.
    • toolbar_field: Use this property to change the background color of the Awesomebar. This property is also supported by Chrome themes.
    • toolbar_field_text: Use this property to change the foreground color of the Awesomebar, thus the text you type in it. This property is also supported by Chrome themes.
    • toolbar_field_border: Use this property to change the color of border of textboxes other than the Awesomebar inside toolbars. (Since Firefox 59.)
    • toolbar_top_separator: Use this property to change the color of the top border of a toolbar that visually separates it from other toolbars above it. (Since Firefox 58.)
    • toolbar_bottom_separator: Use this property to change the color of the bottom border of a toolbar, that visually separates it from other toolbars below it. (Since Firefox 58.)
    • toolbar_vertical_separator: The color of the separator next to the application menu icon. (Since Firefox 58.)
    • toolbar_field_separator: The color of separators inside the URL bar.
  • properties
    • additional_backgrounds_alignment: Paired with the ‘additional_backgrounds’ property, you can specify the preferred position for each of the images you specified, in a JavaScript Array.
    • additional_backgrounds_tiling: Paired with the ‘addition_backgrounds’ property, you can specify the preferred tiling mode for each of the images you specified, in a JavaScript Array.

You can find a fantastic primer on browser themes and plenty of examples on MDN and https://github.com/mdn/webextensions-examples/tree/master/themes.

I would like to highlight the VivaldiFox extension in particular, created by Tim Nguyen; he not only worked on this extension but also stepped up to implement some of the missing properties that he needed! Also read his excellent Mozilla Hacks article.

Do you want a more playful introduction to all this tech talk and wish you could fiddle with these properties interactively? Your wish may be granted by our very own John Gruen:

What you can use in the future

Static themes, which only contain a manifest and image resources, will be supported on addons.mozilla.org (AMO) early this year. These will replace LightWeight Themes in a backward and forward compatible way. Until that time comes you will be able to experiment locally using about:debugging and by submitting dynamic themes that use the JavaScript API as explained above.

At this moment of writing, we’ve implemented most of the properties that Chrome supports to theme the browser. Going beyond that, we’re looking to add support for about:home custom themes and possibly for other in-content pages as well.

A group of students from Michigan State University (MSU) will be working on adding the remainder of Chrome properties and more.

One of the most exciting things to come in the near future is the ‘Theme Experiments’ API: on the Nightly channel, you can write an extension that is able to style a part of the browser UI that we haven’t implemented yet, using CSS selectors to make up your properties for it. This way it’s possible to propose new manifest properties to be added to the current set and have them become a part of Firefox, so every theme author can use it and every user may enjoy it!

Our hope is that with this in place the Theming API will evolve continuously to adapt to your needs, because we know that a good API is never ‘done’.

Get involved

If you want to help us out – yes please! – the easiest thing to start with is file bug reports with the things you think are missing today, blocking this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=themingapi.

Don’t worry about duplicate bug reports too much, we’re actively pruning the list and rather have too many than an incomplete API.

If you want to implement the next property or API method yourself, please join us on IRC in the #webextensions channel or send a message to the dev-addons mailing list!

Updates to Add-on Review Policies

The Firefox add-ons platform provides developers with a great level of freedom to create amazing features that help make users’ lives easier. We’ve made some significant changes to add-ons over the past year, and would like to make developers aware of some updates to the policies that guide add-ons that are distributed publicly. We regularly review and update our policies in reaction to changes in the add-on ecosystem, and to ensure both developers and users have a safe and enjoyable experience.

With the transition to the WebExtensions API, we have updated our policies to better reflect the characteristics of the new technology, and to better clarify the  practices that have been established over the years.

As existing add-ons may require changes to comply with the new policies, we would like to encourage add-on developers to preview the policies, and make any necessary preparations to adjust their add-ons.

Some notable changes and clarifications include:

  • With some minor exceptions for add-ons listed on addons.mozilla.org, all policies apply to any add-ons that are distributed to consumers in any manner.
  • Add-on listings should have an easy-to-read description about everything it does.
  • Add-ons that contain obfuscated, minified or otherwise machine-generated code, must provide the original, non-generated source code to Mozilla during submission as well as instructions on how to reproduce the build.
  • Add-ons that collect, store, use or share user data must clearly disclose the behavior in the privacy policy and summarize it in the description. Users must be provided with a way to control the data collection.
  • Collecting data not explicitly required for the add-on’s basic functionality is prohibited. Add-ons must only collect information about add-on performance and/or use.

If you have questions about the updated policies or would like to provide feedback, feel free to reply on the discourse thread.

The new policies will be effective April 1, 2018.

March’s Featured Extensions

Firefox Logo on blue background

Pick of the Month: Clippings

by AE Creations
Save frequently entered text for future pasting.

“Very easy to use. This add-on is definitely a keeper.”

Featured: Unpaywall

by Impactstory
Great for academics or curious minds of any sort, Unpaywall can access nearly 100 million scholarly papers typically hidden behind paywalls.

“Great add-on that helps to empower the exchange of knowledge, which empowers the world! Truly a forward thinking and progressive add-on.”

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!

Discontinuing support for beta versions

addons.mozilla.org (AMO) has supported a way for developers to upload beta versions of their add-ons. This allowed power users to test upcoming features and fixes before they are published to all users. It has been a useful feature to have for some developers.

However, the feature suffers from a few problems:

  • Users can’t be easily moved to the release channel. This can strand users in an abandoned beta channel.
  • Because of this, the beta channel needs to be updated as frequently as the release channel.
  • It adds complexity to some of the most complex AMO code.

For these reasons, and because usage of this feature is low, we will be discontinuing support for this feature in the next month.

Using self-hosted versions for testing

AMO supports signing self-hosted (unlisted) versions, which we believe is a good replacement. With self-hosted versions, developers can create multiple development update channels if needed. They can easily move users between channels. The main caveat is that the files and update mechanisms need to be hosted by the developer. This documentation on add-on distribution explains this a little further.

We communicated this change to developers who use beta versions a few weeks ago. If you have a beta version installed, you may be notified soon with instructions on how to move forward. We also recommend that you visit the add-on’s listing page for any updates from the developer.

This change will ease AMO development moving forward. Moreover, it helps us work on new features that more users will enjoy. If you have questions or comments about this, we invite you to join this discussion thread.

 

Using Permissions to Establish Trust

TrustI used to work in an industry where being ISO 9001 certified was necessary in order to remain competitive. If you are unfamiliar with ISO 9001, it is a set of standards that requires a business to document each process, and then follow those documented processes. And every autumn, sure as the leaves falling from the trees, an independent auditor would show up to verify we were indeed documenting and following our processes. It’s like a tax audit you impose on yourself (and about as unpleasant).

The idea behind ISO 9001, though, is that a certified business can be trusted, both in its business dealings and its delivered products. It is meant to convey a sense of quality and security to customers.

Firefox (thankfully) is not subject to ISO standards, but we still ask users to trust us. This is especially true for extensions. How do we communicate that a user should trust an extension when, conceivably, it has access to every site the user visits and can see each byte of data the user sends and receives.

A primary way Firefox builds trust with users is by showing them what an extension is capable of doing via permissions.  During installation, the user is presented with a list of permissions that the extension has requested, and that list must be explicitly confirmed before installation proceeds. As developers we can take advantage of this opportunity to connect with our users. Fully explaining the permissions we need (on the landing page, in the listing, and/or in the extension itself) and why we need them creates trust in our extension and faith in Firefox.

Chrome has had this type of permission system for some time, and most people are used to seeing this on their mobile phones where, for years, applications have asked for permissions when installed.  Long time Firefox users, however, may not be used to seeing this prompt, as it is relatively new, introduced with the WebExtensions API. Therefore, as developers, we should only ask for the permissions our extension absolutely needs, demonstrating respect for user privacy and reinforcing the trust bond with our users.

Mozilla provides material on this blog and on our support site to help users better understand what is happening with permissions. For developers, this article on MDN goes into more detail on ways to request and use appropriate permissions.  Following that advice can help gain and maintain trust in extensions, without the pain of an ISO 9001 audit.

 

Removing Support for Unpacked Extensions

With the release of Firefox 62 (currently scheduled for August 21, 2018) Mozilla will discontinue support for unpacked sideloaded extensions. You will no longer be able to load an extension via the Windows registry by creating an entry with an extension’s directory (i.e. unpacked) after Firefox 61. Starting with Firefox 62, extensions sideloaded via the Windows registry must be complete XPI files (i.e. packed).

 

Removing a Legacy Heritage

Support for unpacked extensions was originally a feature used by legacy extensions. With the release of Firefox Quantum (57) and the transition to the WebExtensions architecture for add-ons, support for unpacked extensions is no longer required. Maintaining support for both unpacked and packed extensions places a significant technical burden on the engineering and testing organizations, and removal of the legacy unpacked extension code helps Mozilla preserve the long-term stability of Firefox.

Convert Unpacked to Packed

If you are the developer of an extension that has been installed via the Windows registry as an unpacked directory, your extension will continue to work through Firefox 61. Starting with Firefox 62, however, your extension will be no longer be loaded by Firefox. To avoid this situation and ensure users do not lose functionality, please pack your extension and update the Windows registry entry to use the packed XPI file (see MDN for detailed instructions).

Development Still Supports Unpacked Extensions

Note: this does not impact the use of unpacked extensions for development. Temporarily loading and debugging an extension either via the about:debugging page or via the web-ext tool will continue to be supported; both methods will still be able to load extensions contained within a filesystem directory. Developers will not be required to sign or pack their extensions into an XPI file for development purposes.

February’s Featured Extensions

Firefox Logo on blue background

Pick of the Month: Swift Selection Search

by Daniel Lobo
Access multiple search engines in a pop-up panel when you highlight text on any web page.

“Best time saving extension ever.”

Featured: Imagus

by Deathamns
Mouse over links to enlarge their thumbnails or videos.

“It just works. Nice, simple and clean. There may be more fancy ways of using it but I’m a simple guy.”

Featured: SmartProxy

by Salar Khalilzadeh
Add any website to your list and SmartProxy will automatically transfer your data from those sites through a proxy.

“Best! Best!”

Featured: Social Fixer

by MattKruse
Adjust Facebook to your liking. Filter posts by content (remove sponsored posts, political commentary, or things your friends Like), author, and more.

“It’s a fantastic little add-on that allows one to highly customize what one sees on FB. Not intrusive, yet very effective. It allows me to hide most of the annoying parts of FB. And it’s FREE!”

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!

Understanding Extension Permission Requests

An extension is software developed by a third party that modifies how you experience the web in Firefox. Since they work by tapping into the inner workings of Firefox, but are not built by Mozilla, it’s good practice to understand the permissions they ask for and how to make decisions about what to install. While rare, a malicious extension can do things like steal your data or track your browsing across the web without you realizing it.

We have been taking steps to reduce the risk of extensions, the most significant of which was moving to a WebExtensions architecture with the release of Firefox 57 last fall. The new APIs limit an extension’s ability to access certain parts of the browser and the information they process. We also have a variety of security measures in place, such as a review process that is designed to make it difficult for malicious developers to publish extensions. Nevertheless, these systems cannot guarantee that extensions will be 100% safe.

Here’s where you come in

We want to make it easier for you to make informed decisions about the extensions you install, by providing transparency about what individual extensions can do. Since transitioning to the WebExtensions API, we have been displaying a permissions message corresponding to the extension you are installing.

Extensions have always had access to this type of information, but by showing you what they are (and telling you what they mean), we hope to help you become more savvy about choosing safe extensions.

How about the scary-sounding one?

There is one permission in particular, “Access your data for all websites”, that we’ve gotten many questions about since the feature launched. The reason why it’s worded this way is because a web page can contain virtually anything, and some extensions need to read everything on it in order to perform an action based on what the page contains.

For example, an ad blocker needs to read all web page content to identify and remove ad code. A password manager needs to detect and write to username and password fields. A shopping extension might need to read details of the products you’re searching for.

Since these types of extensions wouldn’t know whether any particular web page contains the bit it needs to modify until it’s loaded, and neither does Firefox, it needs access to everything on a page so it can look for and modify the appropriate parts. This means that in theory, while rare, a malicious developer could tell you their extension does one thing while it actually does something else.

How do I stay safe?

While there is an element of risk to installing any third-party software, there are a few simple best practices you can follow to reduce it. Is the extension made by a reputable developer? Are the user ratings high? Are the permission requests consistent with the features of the extension?

We’ve compiled a short checklist of questions to consider in our support forum. These best practices can help you evaluate any potential software you install, and feel safer and better informed wherever you are on the web.