Mozilla Add-ons Community Blog
Addons Toolbox
Categories: developers webextensions

WebExtensions and parity with Chrome

10 responses

A core strength of Firefox is its extensibility. You can do more to customize your browsing experience with add-ons than in any other browser. It’s important to us, and our move to WebExtensions doesn’t change that. One of the first goals of implementing WebExtensions, however, is reaching parity with Chrome’s extension APIs.

Parity allows developers to write add-ons that work in browsers that support the same core APIs with minimum fuss. It doesn’t mean the APIs are identical, and I wanted to clarify the reasons why there are implementation differences between browsers.

Different browsers

Firefox and Chrome are different browsers, so some APIs from Chrome do not translate directly.

One example is tab highlight. Chrome has this API because it has the concept of highlighted tabs, which Firefox does not. So instead of browser.tabs.onHighlighted, we fire this event on the active tab as documented on MDN. It’s not the same functionality as Chrome, but that response makes the most sense for Firefox.

Another more complicated example is private browsing mode. The equivalent in Chrome is called incognito mode and extensions can support multiple modes: spanning, split or not_allowed. Currently we throw an error if we see a manifest that is not spanning as that is the mode that Firefox currently supports. We do this to alert extension authors testing out their extension that it won’t operate the way they expect.

Less popular APIs

Some APIs are more popular than others. With limited people and time we’ve had to focus on the APIs that we thought were the most important. At the beginning of this year we downloaded 10,000 publicly available versions of extensions off the Chrome store and examined the APIs called in those extensions. It’s not a perfect sample, but it gave us a good idea.

What we found was that there are some really popular APIs, like tabs, windows, and runtime, and there are some APIs that are less popular. One example is fontSettings.get, which is used in 7 out of the 10,000 (0.07%) add-ons. Compare that to tabs.create, which is used in 4,125 out of 10,000 (41.25%) add-ons.

We haven’t prioritized the development of the least-used APIs, but as always we welcome contributions from our community. To contribute to WebExtensions, check out our contribution page.

Deprecated APIs

There are some really popular APIs in extensions that are deprecated. It doesn’t make sense for us to implement APIs that are already deprecated and are going to be removed. In these cases, developers will need to update their extensions to use the new APIs. When they do, they will work in the supported browsers.

Some examples are in the extension API, which are mostly replaced by the runtime API. For example, use runtime.sendMessage instead of extension.sendMessage; use runtime.onMessage instead of extension.onRequest and so on.

W3C

WebExtensions APIs will never completely mirror Chrome’s extension APIs, for the reasons outlined above. We are, however, already reaching a point where the majority of Chrome extensions work in Firefox.

To make writing extensions for multiple browsers as easy as possible, Mozilla has been participating in a W3C community group for extension compatibility. Also participating in that group are representatives of Opera and Microsoft. We’ll be sending a representative to TPAC this month to take part in discussions about this community group so that we can work towards a common browser standard for browser extensions.

Update: please check the MDN page on incompatibilities.

10 comments on “WebExtensions and parity with Chrome”

  1. Fx0 wrote on

    Hi,

    regarding W3C, what’s about Google? If reaching parity with Chrome’s extension API was a goal, does it not make sense that also Google is participating in the W3C community group for extension compatibility?

  2. Aris wrote on

    You are missing what is important here: a FIREFOX user is not a CHROME user. Both expect different browser behavior and features when it comes to non-default browser experience. Examine 10000 current Firefox extensions to see what Firefox users want and are looking for.

    You can not just look into how many Google Chrome users do this or do that and transfer this result over to Firefox users. This does not make any sense. Whats the point of having parity with Chrome anyway? Its not like users can not just install and use Chrome and forget Firefox.

    Why not just fork Chromium, put “Firefox” label on it and forget WebExtensions instead of wasting time and money for developing an own version of them? “WebExtensions” already are part of Chrome, Opera, Vivaldi, Edge and other forks.

    1. Stephan Sokolow wrote on

      Actually, to be honest, I’ve wanted to use Firefox and its existing catalogue of extensions, yet develop WebExtensions ever since Chrome came out.

      I tried developing Firefox and Thunderbird extensions back around Firefox 2.x but found the XUL-related APIs horrendously under-documented and the need to manually re-verify extensions with each update a complete morale killer.

      When Jetpack came out, it seemed like it’d be my answer, but its APIs always felt like they produced results inferior to a XUL extension and I was still waiting for someone on Planet Mozilla to blog about clear, reliable ways to get what WebExtensions would give me when the plan to add WebExtensions was announced.

      If they can manage this transition without killing any of my preferred, currently-XUL extensions or making my XUL Userstyle tweaks impossible, I’m all for it. (Though I’m definitely going to be sticking to portable Greasemonkey/Tampermonkey scripts for stuff meant for public consumption. Not everyone is on developer edition where extension signing can be disabled.)

      Plus, e10s is long overdue specifically because the old APIs tie extensions too strongly to the old, single-process implementation and I’m the first Firefox nut to admit that Firefox is horrendously sluggish under any reasonable number of tabs and the only reason Firefox wins on the various non-RAM “are we * yet” sites is because they’ve abdicated their responsibility to provide essential features in the core where the CI infrastructure can monitor them. (It feels as if they only use “must fit in better with platform-native apps” as a justification when throwing out features, not adding things like scroll-wheel tab switching that every other native app AND browser has built-in.)

  3. Stephan Sokolow wrote on

    If you’re not going to implement deprecated extensions, please differentiate “not supported, yet” and “not supported, deprecated” on AreWeWebExtensionsYet.com.

    It took me a while to realize that my “scan down, glancing between support badge and rank badge on each row” methodology was flawed.

    1. Stephan Sokolow wrote on

      Ugh. Deprecated APIs, not deprecated extensions.

      (I need to remember not to check my feeds when I wake up to get a drink of water.)

    2. Andy McKay wrote on

      Sure I’ll try to do that. That site was there mostly as a reference while MDN documentation caught up. But MDN documentation is there and really good and I recommend that as the definitive guide now. Check out this page: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Browser_support_for_JavaScript_APIs and deprecations are noted in the docs.

      1. Stephan Sokolow wrote on

        I actually was aware of that page, but I can never remember the URL for it. AreWeWebExtensionsYet is easy.

        Also, while I agree that the MDN page is better for most uses, it still doesn’t show deprecation in a scannable way (ie. I have to click a link to see what the asterisk means).

        …not to mention that, if you just want to see where Firefox is still catching up, it takes more mental effort to ignore “spurious” patches of red in columns for other browsers.

        1. john wrote on

          even a google search cant find ONE single so called web extention really dissapointed in firefox was my browser for 15 yrs now im using maxthon until i see this mysterious multi process and web ext

  4. Rich wrote on

    Hi there, just wondering if you’re planning on implementing bookmarks events (onChanged/onCreated/onMoved/onRemoved)? I would imagine quite a few extensions would use these events.

    1. Andy McKay wrote on

      Yes, the bug is here https://bugzilla.mozilla.org/show_bug.cgi?id=1221764