Extensions in Firefox 63

Firefox 63 is rolling into Beta and it’s absolutely loaded with new features for extensions. There are some important new API, some major enhancements to existing API, and a large collection of miscellaneous improvements and bug fixes. All told, this is the biggest upgrade to the WebExtensions API since the release of Firefox Quantum.

An upgrade this large would not have been possible in a single release without the hard work of our Mozilla community. Volunteer contributors landed over 25% of all the features and bug fixes for WebExtensions in Firefox 63, a truly remarkable effort. We are humbled and grateful for your support of Firefox and the open web. Thank you.

Note: due to the large volume of changes in this release, the MDN documentation is still catching up. I’ve tried to link to MDN where possible, and more information will appear in the weeks leading up to the public release of Firefox 63.

Less Kludgy Clipboard Access

A consistent source of irritation for developers since the WebExtensions API was introduced is that clipboard access is not optimal. Having to use execCommand() to cut, copy and paste always felt like a workaround rather than a valid way to interact with the clipboard.

That all changes in Firefox 63. Starting with this release, parts of the official W3C draft spec for asynchronous clipboard API is now available to extensions. When using the clipboard, extensions can use standard the WebAPI to read and write to the clipboard using navigator.clipboard.readText() and navigator.clipboard.writeText().  A couple of things to note:

  • clipboard.writeText is available to secure contexts and extensions, without requiring any permissions, as long as it is used in a user-initiated event callback.  Extensions can request the clipboardWrite permission if they want to use clipboard.writeText outside of a user-initiated event callback. This preserves the same use conditions as document.execCommand(“copy”).
  • clipboard.readText is available to extensions only and requires the clipboardRead permission. There currently is no way to expose the clipboard.readText API to web content since no permission system exists for it outside of extensions. This preserves the same use conditions as document.execCommand(“paste”).

In addition, the text versions of the API are the only ones available in Firefox 63.  Support for the more general clipboard.read() and clipboard.write() API are awaiting clarity around the W3C spec and will be added in a future release.

Selecting Multiple Tabs

One of the big changes coming in Firefox 63 is the ability to select multiple tabs simultaneously by either Shift- or CTRL-clicking on tabs beyond the currently active tab. This allows you to easily highlight a set of tabs and move, reload, mute or close them, or drag them into another window.  It is a very convenient feature that power users will appreciate.

In concert with this user-facing change, extensions are also gaining support for multi-select tabs in Firefox 63.  Specifically:

  • The tabs.onHighlighted event now handles multiple selected tabs in Firefox.
  • The tabs.highlight API accepts an array of tab indices that should be selected.
  • The tabs.Tab object properly sets the value of the highlighted property.
  • The tabs.query API now accepts “highlighted” as a parameter and will return an array of the currently selected tabs.
  • The tabs.update API can alter the status of selected tabs by setting the highlighted property.

A huge amount of gratitude goes to Oriol Brufau, the volunteer contributor who implemented every single change listed above.  Without his hard work, multi-select tabs would not be available in Firefox 63. Thank you, Oriol!

P.S.  Oriol wasn’t satisfied doing all of the work for multi-select tabs, he also fixed several issues with extension icons.

What You’ve Been Searching For

Firefox 63 introduces a completely new API namespace that allows extensions to enumerate and access the search engines built into Firefox.  Short summary:

  • The new search.get() API returns an array of search engine objects representing all of the search engines currently installed in Firefox.
  • Each search engine object contains:
    • name (string)
    • isDefault (boolean)
    • alias (string)
    • favIconUrl (URL string)
  • The new search.search() API takes a query string and returns the results. It accepts an optional search engine name (default search engine is used, if omitted) and an optional tab ID where the results should be displayed (opens a new tab, if omitted).
  • Extensions must declare the search permission to use either API.
  • The search.search() API can only be called from inside a user-input handler, such as a button, context menu or keyboard shortcut.

More Things to Theme

Once again, the WebExtensions API for themes has received some significant enhancements.

  • The built-in Firefox sidebars can now be themed separately using:
    • sidebar
    • sidebar_text
    • sidebar_highlight
    • sidebar_highlight_text
  • Support for theming the new tab page was added via the properties ntp_background and ntp_color (both of which are compatible with Chrome).
  • The images in the additional_backgrounds property are aligned correctly to the toolbox, making all the settings in additional_backgrounds_alignment work properly.  Note that this also changes the default z-order of additional_backgrounds, making those image stack on top of any headerURL image.
  • By default, all images for additional_backgrounds are anchored to the top right of the browser window.  This was variable in the past, based on which properties were included in the theme.
  • The browser action theme_icons property now works with more themes.
  • Themes now enforces a maximum limit of 15 images for additional_backgrounds.
  • The theme properties accentcolor and textcolor are now optional.

Finally, there is a completely new feature for themes called theme_experiment that allows theme authors to declare their own theme properties based on any Firefox CSS element. You can declare additional properties in general, additional elements that can be assigned a color, or additional elements that can be images.  Any of the items declared in the theme_experiment section of the manifest can be used inside the theme declaration in the same manifest file, as if those items were a native part of the WebExtensions theme API.

theme_experiment is available only in the Nightly and Developer editions of Firefox and requires that the ‘extensions.legacy.enabled’ preference be set to true.  And while it also requires more detailed knowledge of Firefox, it essentially gives authors the power to completely theme nearly every aspect of the Firefox user interface. Keep on eye on MDN for detailed documentation on how to use it (here is the bugzilla ticket for those of you who can’t wait).

Similar to multi-select tabs, all of the theme features listed above were implemented by a single contributor, Tim Nguyen. Tim has been a long-time contributor to Mozilla and has really been a champion for themes from the beginning. Thank you, Tim!

Gaining More Context

We made a concerted effort to improve the context menu subsystem for extensions in Firefox 63, landing a series of patches to correct or enhance the behavior of this heavily used feature of the WebExtensions API.

  • A new API, menus.getTargetElement, was added to return the element for a context menu that was either shown or clicked.  The menus.onShown and menus.onClicked events were updated with a new info.targetElementId integer that is accepted by getTargetElement.  Available to all extension script contexts (content scripts, background pages, and other extension pages), menus.getTargetElement has the advantage of allowing extensions to detect the clicked element without having to insert a content script into every page.
  • The “visible” parameter for menus.create and menus.update is now supported, making it much easier for extensions to dynamically show and hide context menu items.
  • Context menus now accept any valid target URL pattern, not just those supported by valid match patterns.
  • Extensions can now set a keyboard access key for a context menu item by preceding it with the & symbol in the menu item label.
  • The activeTab permission is now granted for any tab on which a context menu is shown, allowing for a more intuitive user experience without extensions needing to request additional permissions.
  • The menus.create API was fixed so that the callback is also called when a failure occurs
  • Fixed how menu icons and extensions icons are displayed in context menus to match the MDN documentation.
  • The menus.onClick handler can now call other methods that require user input.
  • menus.onShown now correctly fires for the bookmark context.
  • Made a change that allows menus.refresh() to operate without an onShown listener.

Context menus will continue to be a focus and you can expect to see even more improvements in the Firefox 64 timeframe.

A Motley Mashup of Miscellany

In addition to the major feature areas mentioned above, a lot of other patches landed to improve different parts of the WebExtensions API.  These include:

Thank You

A total of 111 features and improvements landed as part of Firefox 63, easily the biggest upgrade to the WebExtensions API since Firefox Quantum was released in November of 2017.  Volunteer contributors were a huge part of this release and a tremendous thank you goes out to our community, including: Oriol Brufau, Tim Nguyen, ExE Boss, Ian Moody, Peter Simonyi, Tom Schuster, Arshad Kazmi, Tomislav Jovanovic and plaice.adam+persona. It is the combined efforts of Mozilla and our amazing community that make Firefox a truly unique product. If you are interested in contributing to the WebExtensions ecosystem, please take a look at our wiki.

 

14 responses

Post a comment

  1. zakius wrote on :

    so, still no support for mouse gestures, no support for native UI components, no official Pocket extension with feature parity of the great, old one you gave up on years ago… yeah, “progress”

    Reply

  2. Robert Ab wrote on :

    **ExtensionStorageIDB / indexedDB**

    This future is coming to:
    Firefox 62 – https://bugzilla.mozilla.org/show_bug.cgi?id=1406181
    Firefox 63 – https://bugzilla.mozilla.org/show_bug.cgi?id=1474562

    But there is bug 944918 (https://bugzilla.mozilla.org/show_bug.cgi?id=944918) which is still not fixed yet. This bug is causing problems for WebExtensions using this database storage, like Tab Session Manager:
    https://github.com/sienori/Tab-Session-Manager/wiki/IndexedDB-Error
    https://github.com/sienori/Tab-Session-Manager/issues/210
    https://github.com/sienori/Tab-Session-Manager/issues/222
    https://github.com/sienori/Tab-Session-Manager/issues/239
    https://bugzilla.mozilla.org/show_bug.cgi?id=944918#c25
    https://bugzilla.mozilla.org/show_bug.cgi?id=944918#c37

    It is very probable that other WebExtensions also experiencing this bug.

    Reply

    1. Juraj M wrote on :

      Tell me about it. My Group Speed Dial is using IndexedDB and I get several e-mails about this error every week.

      Does this mean that whole Firefox will crash instead of just my add-on? That would be great because people would not contact me anymore (blaming my add-on).

      Or does that mean that when the crash happens, they loose also their data in storage.local? That would be terrible – because right now they can at least export their data because only IndexedDB is inaccessible.

      Reply

      1. Robert Ab wrote on :

        I can see that you reported problem:
        https://bugzilla.mozilla.org/show_bug.cgi?id=944918#c22

        Seniori (TSM developer) placed also information about this error on his addon page:
        https://addons.mozilla.org/en-US/firefox/addon/tab-session-manager/

        Do the same, so people will know who should be blamed for this. Report all important bugs causing errors.

        Reply

      2. Robert Ab wrote on :

        Finally. Bug 944918 (https://bugzilla.mozilla.org/show_bug.cgi?id=944918) was assigned. Thank you Mozilla.

        Reply

  3. Esapadaguy wrote on :

    Hi Mike,

    Not sure if this is within your area, but can something like “Classic Theme Restorer” be integrated into Quantum. I use it on one computer running ESR 52.9.0 and I am looking for a new browser on another computer because Quantum 61.0.2. has a horrible look and I cannot find a way to make it look “right” and I understand that Classic Theme Restorer will soon not work any longer, even on ESR (is this correct?).

    Why not have a setting that allows selection of “new” and “old” layouts? If I have to deal with the new look I will have to find another browser. Why ruin the things that attracted your users in the first place?

    This is like the introduction of “New Coke” where Coca-Cola abandoned one of the most successful products of all time and replaced it with something almost no one bought. Don’t do that to yourselves!

    E..

    Reply

    1. jscher2000 wrote on :

      The legacy Classic Theme Restorer extension can’t work on any ESR based on Firefox 60 or later.

      The author of CTR has made much of its restyling capability available for Firefox 57+ here:

      https://github.com/Aris-t2/CustomCSSforFx/

      For general assistance with custom CSS, consider using: https://www.reddit.com/r/FirefoxCSS/

      My site is available as a general reference: https://www.userchrome.org/

      Reply

    2. Jake wrote on :

      Wasn’t CTR just a thing that let you undo the round tabs? They are gone and firefox now has straight tabs again. What exactly are you missing? I think everything that CTR could do, you can do with custom CSS.

      Reply

  4. Kees wrote on :

    Can you indicate how much of the top 100 add-ons can be implemented without any issues using WebExtensions? (As this should have been the driving factor for any new API’s; ensure that when the ESR with XUL/XPCOM support is replaced with a new one, the WE API is feature complete so that the top 100 add-ons can be implemented without compromise). The next step would be checking what is still missing related to the other add-ons

    A few examples of add-ons not working yet in WE-world: Overbite, FireFTP. Also the TileTabs is still not working in a user friendly manner. Currently it is using windows to fake proper tiling, please ensure that a proper api is implemented so that the classic (and much better[!]) XUL-based solution is possible.

    Reply

    1. def00111 wrote on :

      OverbiteWX
      https://addons.mozilla.org/firefox/addon/overbitewx

      Reply

    2. Chuck Baker wrote on :

      It is unlikely that FireFTP will ever be available for Quantum. Like some of my extensions (FEBE, CLEO, OPIE) it requires access to the user’s filesystem (search, read, write permissions).

      This is something that WE does not allow at this time, and I seriously doubt will ever be allowed.

      Reply

  5. kjemmo wrote on :

    Still no toolbar API… Thought it would land in this version and if not in version 64. Now I can see that a toolbar API has been pushed even further into the future and that it is not even decided when it will it will be available.

    https://wiki.mozilla.org/Add-ons/Projects#New_WebExtension_APIs

    You are aware that developers can add only one button to Firefox? That is it one single button. Really? I am starting to think that it is embarrassing that WebExtensions is limited this way.

    As it is, it is impossible to provide any meaningful user-interface for just slightly complex extensions.

    I am so disappointed.

    Reply

    1. Bill Hayden wrote on :

      I can’t agree more. The toolbar api should be a top priority. The old extension format should never have been deprecated before a suitable toolbar api was ready to go.

      Reply

  6. Juraj M wrote on :

    This is my favorite Blog! I really like new features – I’m looking forward to it every 6 weeks!
    However now I’m getting a bit disappointed with new bugs, that are being introduced also every 6 weeks 🙁

    I remember in Firefox 61 I’ve read about new Tabs Hiding feature, and now in 63 I discovered it’s being “affected” by new (default!) MRU tabs switching: https://bugzilla.mozilla.org/show_bug.cgi?id=1488168

    Now I have a feeling there should be a blog called “Bugs in Firefox XX”.
    Firefox 62 – broken focus in new windows: https://bugzilla.mozilla.org/show_bug.cgi?id=1458842
    Firefox 61 – “about:home” stopped working: https://bugzilla.mozilla.org/show_bug.cgi?id=1468191
    Firefox 60 – no more extensions in PDF: https://bugzilla.mozilla.org/show_bug.cgi?id=1454760

    … and there is more! Like broken Find API: https://bugzilla.mozilla.org/show_bug.cgi?id=1448564

    Isn’t there a way to fix bugs faster? Like dedicate one day a week when all developers would just fix the bugs they introduced:)

    Reply

Post Your Comment