Extensions in Firefox 61

Firefox 60 is now in the Release channel, which means that Firefox 61 has moved from Nightly to the Beta channel. As usual, Mozilla engineers and volunteer contributors have been hard at work, landing a number of new and improved WebExtensions API in this Beta release.

Before getting to the details, though, I’d like to note that the Firefox Quantum Extensions Challenge has come to an end.  The contest was a huge success and the judges (myself included) were overwhelmed with both the creativity and quality of the entrants.  A huge thank you to everyone who submitted an extension to the contest and congratulations to the winners.

The Case of the Vanishing Tabs

In November of 2017, we made a commitment to enriching the WebExtensions API with additional tab management features, with tab hiding being a top priority.  Since that time, several new and enhanced tab-related API have been added and today, with the release of Firefox 61 to the Beta channel, tab hiding is officially a WebExtensions API.

The usage of the tabs.hide() API was covered in the post on Extensions in Firefox 59.  The main change now is that it is no longer necessary to set the extensions.webextensions.tabhide.enabled preference to true; tab hiding can be used by extensions without setting that preference. In fact, that preference will soon be going away in an upcoming release.

In the user interface, when tabs are hidden, a down-arrow is added to the end of the tab strip. When clicked, this icon shows all of your tabs, hidden and visible, and provides a quick and easy way to keep from losing things (see animation below, and thanks to Afnan Khan for the great Hide Tabs extension).

Hidden Tabs Arrow

In addition, if a hidden tab is playing audio, the audio icon is shown on top of the down-arrow icon.  If you click on the down-arrow, the hidden tab with audio is pulled out so that it is easier to find (see animation below).

Audio Icon For Hidden Tabs

You can expect to see this user interface get a small update in Firefox 62. In particular, it will be modified so that it conforms to the Firefox Photon Design System.

Making Hidden Tabs Visible

As noted above, when an extension hides a tab, Firefox will display a down-arrow in the tab strip that gives users access to all of their tabs, both visible and hidden. This is a simple and easy way to manage hidden tabs, but it is also subtle.  To make sure users are completely aware of hidden tabs, and to discourage malicious and deceitful use of them, Firefox will always show a door hanger when the first tab is hidden.

Hidden Tab Door Hanger

The door hanger informs the user that one or more tabs was hidden by an extension, explains the down-arrow on the tab strip (pointing to it), and gives the user the option to disable the extension.

Even More Tab Stuff

While tab hiding is the biggest feature to land in Firefox 61, a few other highly requested tab features also made it into this release.

A new browserSettings API, openUrlbarResultsInNewTabs, allows extensions to specify if search results from the URL bar should open in the current tab or a new tab.  This complements the existing browserSettings.openBookmarksInNewTabs and browserSettings.openSearchResultsInNewTabs settings.

Also, fine grain control of the opening position for new tabs is now provided via the browserSettings.newTabPosition API.  This new API can take three different values:

  • afterCurrent – open all new tabs next to the current tab
  • relatedAfterCurrent – open child tabs (tabs opened from a link in the current tab) after the current tab
  • atEnd – open all new tabs at the end of the tab strip

Finally, listeners to the tabs.onUpdated event can now supply a filter to avoid the overhead of unwanted events. The filter supports URLs, window and tab ids, and various properties such as “audible”, “discarded”,  “hidden”, “isarticle” and more. Not only does this simplify code inside the listener for developers, it significantly improves browser performance by keeping Firefox from dispatching so many events. Extension developers are strongly encouraged to use this new feature to make their extension and the browser more performant for users.

Themes

It seems we can’t let a release go by without adding to themes, and Firefox 61 is no exception. Check out the new improvements (and the improved documentation on MDN that shows examples of what each theme property modifies).

  • Themes support default_locale; not a theme property, but a standard manifest key
  • Fixed tab_selected so it works when headerURL is not set (uplifted to 60)
  • Fully transparent values are once again allowed in themes
  • All of the toolbar properties now apply to the find bar as well
  • Themes can now set the hover, active and focus colors for buttons and toolbars
  • Autocomplete popups now honor any popup_* theme properties that are set

Cleaning the WebExtensions House

I usually end each blog post with a small section that notes some of the general improvements and/or bug fixes in the release. For Firefox 61, though, there was a concerted to improve the WebExtensions ecosystem.  A substantial number of bug fixes and optimizations landed, enough that I wanted to make sure they were more than just a footnote.

Keeping The User Informed

In addition to making sure users are fully aware of extensions using tab hiding, Firefox 61 also highlights when an extension modifies a user’s Home page by displaying a door hanger.

And to help users better understand when an extension is controlling the New Tab page or Home page, or using the tab hiding feature, the door hanger now shows the name of the controlling extension and includes a “Learn More” link that takes the user to a more detailed explanation on Mozilla’s support site.

New Home Page Door Hanger

Important Proxy Changes

After the release of Firefox 59, we discovered that the implementation of the proxyConfig API was not handling the settings for hostnames correctly, causing non-socks proxy settings to fail. The has been corrected in Firefox 61 and uplifted to Firefox 60.

The discovery and resolution of this bug, however, caused us to reevaluate how WebExtensions exposed proxy settings.  In particular, we asked ourselves why these settings weren’t part of the browser.proxy.* namespace. It is true that the underlying implementation depends upon Firefox browser settings, which is how it ended up as part of the browser.browserSettings.* namespace, but that’s just an internal detail. Every major browser vendor supports proxy settings, and they all support basically the exact same set of settings.

Given that, and the fact that Mozilla should be championing web standards, we decided it made more sense to have the proxy settings live inside the browser.proxy.* namespace. So starting with Firefox 60, the browser.browserSettings.proxyConfig API is now the browser.proxy.settings API.  Extensions developers who want to use this API should request the much more intuitive “proxy” permission instead of the “browserSettings” permission.

Finally, another patch was landed in Firefox 61 so that proxy extensions can start before requests bypass them.

Browser Settings

A few new browser settings are now available to extension developers in Firefox 61:

  • Extensions can now toggle the setting that decides if pages should be rendered with document fonts or not via browserSettings.useDocumentFonts.
  • Along similar lines, extensions can set the preference that decides if a page should be rendered with the document colors, user-selected colors, or user-selected only with high-contrast themes via the browserSettings.overrideDocumentColors API.
  • Extensions can offer users the ability to close tabs by double-clicking them via the browserSettings.closeTabsByDoubleClick API.

Thank You

This was a busy release for the WebExtensions API with a total of 95 features and improvements landed as part of Firefox 61. A sincere thank you goes to our many contributors for this release, especially our community volunteers including: Tim Nguyen, Oriol Brufau, Vivek Dhingra, Tomislav Jovanovic, Bharat Raghunathan, Zhengyi Lian, Bogdan Podzerca, Dylan Stokes, Satish Pasupuleti, and Sören Hentzschel. It is only through the combined efforts of Mozilla and our amazing community that we can ensure continued access to the open web. If you are interested in contributing to the WebExtensions ecosystem, please take a look at our wiki.

12 responses

  1. timendum wrote on :

    For breaking changes, like for proxyConfig, the next time a deprecation period of one version could be used.

    So in Firefox 61 proxyConfig still works but deprecated and in Firefox 62 the rename is permanent.

    It would be nice to developers.

    1. Mike Conca wrote on :

      We would not normally change an API from one version to the next without providing a deprecation period, as you suggest. In this case, though, the proxyConfig API was broken upon initial release in Firefox 59 (bug 1455705).

      So we knew few, if any, developers were using that API in their extensions. That gave us the opportunity to make the change directly, without a deprecation period and without breaking existing extensions. We also uplifted the change to Firefox 60 to minimize the exposure of proxyConfig in the wild, leaving only the (non-functional) proxyConfig API in version 59.

      Does that mean we didn’t impact developers? No, not at all. Any major change like this has impacts, even if developers are only in the design and planning stages of an extension. However, this felt like the rare instance where fixing the broken API, only to deprecate it a few releases later, would actually have a greater negative impact on developers than making a direct change now.

  2. Keiya wrote on :

    Still no TCP sockets? It’s in 62 then, right? It’d have to be, since that release will also mark the end of the last ESR to support traditional extensions, and it’s still impossible to implement a gopher client in extrensions [as was promised when it was removed from core](https://bugzilla.mozilla.org/show_bug.cgi?id=388195#c47)

    1. Mike Conca wrote on :

      TCP sockets will not be part of 62. We’d love to be able to provide native TCP and UDP support to extensions, but that comes with some serious privacy and security concerns for users. Working through those will take time and, to be honest, may not be entirely possible to the extent that most developers would wish.

  3. Bill Hayden wrote on :

    Will the necessary API to allow multiple rows of tabs be finally implemented in 61? That’s the main thing I’ve been waiting for since the old API went away. Tab Mix Plus is an essential add-on in my book, and it’s keep me on old, unsupported version of Firefox until this gets resolved. There’s simply no good way to deal with 50+ tabs in a window without it.

    1. Mike Conca wrote on :

      Multi-row tabs will not be part of 61. Your sentiment around TabMixPlus is a common one, and we’ve been adding additional tab API with each release. With tab hiding landing in 61, I would expect to see some new session and tab management extensions appear that help users be more productive with large numbers of tabs.

    2. Drago wrote on :

      I also really want this! I really hope it gets added soon. WebExtensions are so restrictive 🙁

  4. Dan wrote on :

    It seems slow to get WebExtensions APIs into FF, even when the code has been implemented. For example the code to implement sidebar.setPage (https://bugzilla.mozilla.org/show_bug.cgi?id=1398734) was written 8 months ago 🙁

  5. tiago wrote on :

    Is it possible to bring tile tabs to firefox? It’s missing and most browsers like (Vivaldi) have a kind of mosaic tabs and it’s very useful.

  6. Nadya wrote on :

    I use an older version of Firefox (FF38) because I rely heavily on a feature that the add-on Fire Gestures provided. It was the ability to get a list of all of my tabs in a context menu popout, similar to how the “Hidden Tabs” context menu is in the examples of this blog, but it was an independent popout.

    It is shown on the “Wheel Gestures” image for this example: http://www.xuldev.org/firegestures/features.php

    Is there any possibility this functionality could be brought to the Tabs.API in the future? Tabs are a complete waste of UI space and I would prefer to keep them in an accessible-anywhere-on-the-page context menu.

  7. MozReplUser wrote on :

    When can we get something like MozRepl back?
    https://github.com/bard/mozrepl
    MozRepl is an addon that starts up a telnet server which allows execution of javascript in both XUL browser and web page context. I use it for various automation tasks via external programs (written in C++ and AutoHotKey).
    I understand that this is not something the average user does or needs, but that was what Firefox was all about!! Customizable and extendible, it was mine and your browser! Now it’s just another useless browser.

  8. Nikki wrote on :

    If I could make a suggestion for the next update with Firefox, it would be there needs to be a way to hide the status bar that is on the left bottom corner of Firefox. It is highly annoying and distracting. The Status-4-ever add-on was great when it was compatible with the older Firefox versions, as it hid the status bar.