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:
The tabs API now supports a tabs.captureTab method which can be passed a tabId to capture the visible area of the specified tab (as opposed to the tabs.captureVisibleTab API, which only captured the active tab of a window).
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:
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:
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).
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’sblog post about her experience applying to the program.
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.
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.
What you can use today
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.
theme.onUpdated, an event that’s fired whenever the active theme is updated.
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:
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.
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.
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’.
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-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.
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.
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.
I 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.
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.