Mozilla Add-ons Community Blog
Categories: developers webextensions

Results of the WebExtensions API Survey

8 responses

In March, we released a survey asking add-on developers which APIs they need to transition successfully to WebExtensions. So far, 235 people have responded, and we’ve summarized some of the findings in these slides.

Developers with the most add-ons responded at a disproportionate rate. Those with 7 or more add-ons represent 2% of the add-on developer community, and those with 4-6 add-ons represent 3%, but they comprised 36.2% of survey respondents. This didn’t come as a surprise, since the most active developers are also the most engaged and have the most to gain by migrating to WebExtensions.

How many add-ons have you worked on?

Nearly half of respondents have tried implementing their add-ons in Chrome, and the most cited limitation is that it’s restrictive. Developers could not do much with the UI other than add buttons or content tabs. We intend to offer APIs that give developers more freedom to customize their add-ons, and these results tell us we’re on the right track.

In the coming months, we’ll draw on these results to inform our decisions and priorities, to ensure WebExtensions lives up to it promise…and goes beyond.

8 comments on “Results of the WebExtensions API Survey”

  1. Ben Bucksch wrote on

    Your “which APIs do you use” assumes that the GChrome implementation is sufficient. Your slides give the impression that you’re already covering most of it (e.g.sentences like “UI APIs that aren’t covered by WebExtensions and were requested often: devtools.”), so it appears you’re in a good state already.

    But your respondents said that GChrome is too limited. Therefore, you cannot compare WebExtensions API coverage with GChrome API coverage. It’s the wrong bar. The bar are XUL extensions.

    The better approach would be to use the source code of Addons that you have in AMO (for open-source and even closed source addons), and analyze it. Or analyze the exts at runtime, which XPCOM APIs they use. Your target is API coverage of XUL extensions.

    We are developing primarily for Firefox, exactly because Firefox gives so much more capabilities, it’s not even a *comparison* with Google Chrome. It’s like an mosquito vs. a Ferrari. Whereby Firefox is the Ferrari.

    Don’t turn yourself into the mosquito, please!

  2. Joe wrote on

    The graph shows that the “7 or more” was the 18.3% group, not the 63.8%. Overly representative of the 2% for sure, but not so extreme like that.

    1. Amy Tsay wrote on

      Excellent catch–thanks Joe! We’ve updated the post with the correct number.

  3. Ulf3000 wrote on

    Please don´t forget to implement unsafeWindow (if it is already don´t remove it ) … its one of the best features to hack a websites behaviour.

    1. Jorge Villalobos wrote on

      It’d be more useful to know in which situations you use it, so we can figure out if there are APIs we can implement for that behavior. unsafeWindow is risky and it the kind of thing we would avoid implementing.

  4. Brett Zamir wrote on

    “We intend to offer APIs that give developers more freedom to customize their add-ons”. This phrase is encouraging if it means you are not limiting yourself to the APIs of Chrome. Yet your wiki page at https://wiki.mozilla.org/Add-ons/developer/communication still says “existing methods for add-on development such as XUL/XPCOM will be deprecated”. This makes it sound like the SDK is also being deprecated (along with its ability to grant chrome privileges).

    As Ben Bucksch stated, and many others here have stated here very well and what should be convincingly, Firefox’s one very special feature has been its power, even if it seems like it is being neutered at every turn. There seems to be such a strong group-think among everyone but your add-on developers who keep pleading this seemingly without being heard.

    1. Erik wrote on

      If the current rate of market share decline for Firefox continues, then in four years Firefox will have a less than 2.5% market share – the market share that Opera was at when it abandoned the Presto engine.

      This assumes the rate of decline holds, which it is not doing. It is accelerating.

      The Mozilla mission is not to make Firefox. It is to guarantee an open, powerful web and an open powerful internet, and Firefox is a tool to achieve that goal.

      Energy spent on XUL/XPCOM is energy spent maintaining and extending a major set of non-web, non-standard, non-shared APIs. That might be valuable time and energy spent if maintaining those APIs kept Firefox’s market share up and kept Gecko positioned to prevent the web from becoming a Blink/WebKit monoculture.

      But it’s not. While there are plenty of users who want to customize their browsing experience they are the minority. The majority want the *apps they use in the web* to be fast and stable, and ad blocking on top, then they’re pretty much done. And stability in XUL/XPCOM is a barrier to making Gecko able to compete as a pure rendering engine. Not to mention that for users who DO use add-ons the “everything is a monkeypatch” model is hardly secure or performant.

      Am I super happy with these changes? No, I wish they had happened earlier, and moved more slowly. I wish Jetpack had become the place where this sane world was developed, and XUL and XPCOM could be shuffled off as usage in add-ons declined, instead of just looping us back to where we started.

      I also have a bunch of “I wish…” regrets about embedability that are off topic here, but the point stands. As long as I can remember, any discussion to move away from XUL has resulted in backlash from add-on devs. And that is reasonable – add-on devs should make their needs and desires clear. But this change in direction is not for the benefit of add-on devs, or add-on users, it is an emergency attempt to staunch the damn bleeding, with the hope that embracing and extending Chrome can keep critical add-ons from going away.

      Please, let’s hold Mozilla’s feet to the fire on what the API needs to look like – and hopefully by extension do the same to the Chrome team by having Mozilla show how an extensions API can be both safe AND powerful – but let’s not talk like we don’t know the real reasons this is happening, and that maintaining XUL is an option. Let’s find some alternatives

      1. user wrote on

        Your post, sir, is the first that made real sense on why this whole thing is happening. Thank you.