April’s Featured Extensions

Firefox Logo on blue background

Pick of the Month: Passbolt

by Passbolt
A password manager made for secure team collaboration. Great for safekeeping wifi and admin passwords, or login credentials for your company’s social media accounts.

“The interface is user-friendly, installation is explained step by step.”

Featured: FoxClocks

by Andy McDonald
Display times from locations all over the world in a tidy spot at the bottom of your browser.

“This is one of the best extensions for people who work with globally distributed teams.”

Featured: Video DownloadHelper

by mig
A simple but powerful tool for downloading video. Works well with the web’s most popular video sharing sites, like YouTube, Vimeo, Facebook, and others.

“Without a doubt the best completely trouble-free add-on which does exactly what it claims to do without fuss, complicated settings, or preferences. It just works.”

Nominate your favorite add-ons

Featured extensions are selected by a community board made up of 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!

Extensions in Firefox 60

Many people read this blog because they’ve written extensions for Firefox in the past. Others, though, know some HTML, CSS, and JavaScript and have been thinking about writing their first extension. Either way, now is the perfect time to jump into the WebExtensions ecosystem.

That’s because we’re having a contest! Develop an extension for Firefox and enter it into the Firefox Quantum Extensions Challenge by April 15, 2018. Your extension could win you a brand-new Apple iPad Pro or a $250 gift card to Amazon.

And if you want to make your extension even better, consider using some of the new WebExtensions API discussed below. These new and improved API are available in Firefox 60, recently released to the Beta Channel.

A Profusion of Theme Properties

Since “Best Dynamic Theme” is one of the award categories for the Firefox Quantum Extension Challenge, let’s start with improvements to Themes. Release 60 adds a pile of new items to the list of elements that can be themed, doubling the number of individual components.  These include:

  • tab_line – Line color of the selected tab.
  • tab_selected – Background color of the selected tab.
  • popup – The background color of popups (such as the arrow panels).
  • popup_border – The border color of popups.
  • popup_text – The text color of popups.
  • tab_loading – The color of the tab loading indicator and the tab loading burst.
  • icons – The color of toolbar icons.
  • icons_attention – The color of toolbar icons in attention state such as the starred bookmark icon or finished download icon.
  • frame_inactive – The same as “accentcolor”, but only applied to inactive windows, provided for Chrome compatibility.
  • button_background_active – The color of the background of pressed toolbar buttons.
  • button_background_hover – The color of the background of toolbar buttons on hover.
  • toolbar_field_separator – The color of separators inside the URL bar (also available in Firefox 59; note that in Firefox 58 it was implemented under toolbar_vertical_separator)
  • toolbar_vertical_separator – The color of the separator next to the application menu icon (also available in Firefox 59; note that in Firefox 58 it corresponds to the color of separators inside the URL bar).

Also new for Firefox 60, the headerURL property is no longer mandatory, removing a somewhat arbitrary condition that made themes a bit clunky in the past.

Remember, the contest awards a prize for the best Dynamic Theme, so use the theme API to control and change the various UI elements in creative ways. Want an awesome tutorial that talks about Dynamic Themes? Check out the video below.

More Tab Features

Consistent with each release since Quantum 57, tabs remain a focus of WebExtension growth and improvement. Several bigger features will land in release 61 (expert Bugzilla miners are likely aware of them already), but Firefox 60 still offers a number of important items:

Improving Debugging and Development

Several new additions landed that make the debugging and development of extensions easier, including:

Proxy Improvements

The proxy API is quickly maturing, and Firefox 60 adds more functionality by adding the asynchronous proxy.onRequest API.  This API is ideal for extensions looking to deal with proxy requests in a background script.  Details are still being documented on MDN at the time of this writing but should be available soon.

Network Extensions Get DNS

Extensions now have access to Firefox’s DNS service to resolve hostnames. The new browser.dns() API takes a hostname string (with optional parameters) and resolves it to a DNS record for that hostname. To use this new API, your extension must declare the “dns” permission.

Dynamic Keyboard Shortcuts

Two new API were added to the Commands namespace that allow extensions to change their keyboard shortcuts at runtime. The first, commands.update, allows an extension to change the shortcut key and/or description associated with a command, while the second, commands.reset, reverts a command back to the keyboard shortcut and description originally specified in the manifest file.

Keeping Users Informed

In keeping with our mission to ensure that users are always informed and in control of what extensions are doing, a few new messages have been added to the browser interface:

Enhancing All the Action

The browserAction, pageAction, and sidebarAction are three of the most commonly used WebExtension features, and all three get some improvement in Firefox 60:

Other Improvements

The items mentioned above highlight some of the bigger and/or more visible changes that appear in Firefox 60. As always, though, many other minor or less visible improvements to WebExtensions also landed, including:

Thank You

A total of 63 features or improvements were landed for WebExtensions as part of Firefox 60 Beta. Thank you to our many contributors for this release, especially our community volunteers including: Tim Nguyen, Oriol Brufau, Richard Marti, Prathiksha Guruprasad, Vinicius Costa e Silva, Vivek Dhingra, Zhengyi Lian, Connor Masini, DW-dev, Bogdan Podzerca, and Dylan Stokes. As always, we sincerely appreciate you helping ensure that individuals have the ability to shape the Internet and their own experiences on it. If you are interested in contributing to the WebExtensions ecosystem, please take a look at our wiki.

This post is going up a bit later than normal and there are already several additions and changes to the WebExtensions API in progress for Firefox 61, so continue watching this space for more information. In the meantime, please continue to send us your feedback.

Correction
An earlier version of this article incorrectly stated that the theme properties popup_highlight and popup_highlight_text were available in Firefox 60, and that popup and popup_text could be used to style the URL and search bar autocomplete panels. All four of those things will actually appear in Firefox 61 (which is available in the Firefox Nightly channel right now).

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.