A word on timescales

Mozilla announced they were switching to the WebExtensions API in August 2015, and declared the implementation “stable” in April 2016. On Twitter, some people are suggesting that this means extension developers have had plenty of time to “fix their stuff”. Firstly, many had to wait longer for the APIs they needed, and some are still waiting now. Secondly, and more importantly, that meant Mozilla had two years to plan for the live rollout. The below are my rough thoughts from a bit of brainstorming and a couple of chats over dinner; I’m sure there are flaws; but I’m sure they could have been worked through given two years of discussion and prototyping.

The API itself

I said I mostly understand why the new API exists. Extensions in older versions of Mozilla and Firefox were able to inject themselves all over the application; this made them very powerful, but very brittle: just about anything that changed in the browser broke someone’s extension. So I can understand the motivation for making a clean break, and a more planned API, to make radical changes “under the hood”.

However, the choice of the same API as Chrome risks reducing Firefox’s USP and ability to innovate. If the Firefox add-on ecosystem becomes a list of Chrome extensions ported across, it will always lag behind. I don’t know much about the priorities set, but I wonder if effort was wasted trying to be compatible with Chrome which could have been spent providing upgrade paths for more extensions which are unique to Firefox.

What they did

An unfiltered search on addons.mozilla.org in a non-Quantum browser currently shows 21,560 extensions; filter to those compatible with Firefox 57, and you get just 6,250. That’s fifteen thousand “legacy”extensions, about 75% of the total. Numbers don’t tell the whole story, and some of those may have been abandoned for some time; but some were actually identified on a site called “Are we WebExtensions yet?” as among the most used.

Firefox 57 features a built in “find a replacement” option; this is not shown to users at startup, or even on the main extensions screen, but requires you to click into a new section called “Unsupported”. There’s a whole blog post to explain how to find this feature, but amusingly it hasn’t been updated so shows a different wording from what I see in the released version.

What they should have done

Don’t Be Agile

This change is too important to let the development cycle dictate the release. Be firm about the blockers, and let the date slip if it needs to. Don’t give Quantum a release number, or a release date, until you’re absolutely sure it will be ready.

Have a firm list of essential APIs, and don’t even consider turning off legacy extensions without them. Work with the authors of the most popular extensions to build this list.

Tag an Enterprise Support Release just before the feature lands, so that anyone using a legacy add-on in an enterprise setting has the maximum time to transition.

Rather than a forum nobody has ever seen before, ask for suggestions via a big, easy-to-use web form. If you’re maintaining everything by hand anyway, it can just e-mail someone.

When you do get suggestions, have a quick look if they can be used elsewhere. For instance, if someone points out a new WebExtension for mouse gestures, consider listing it for all the other legacy mouse gesture extensions as well.

Don’t arbitrarily pick exactly one suggestion for every extension. Let people say “actually, I prefer this one”, and list the options.

Engage Developers

When a developer uploads a web extension, let them enter the legacy extensions they think it would be a good replacement for, and link them up in the database. If a developer isn’t planning to update their extension, encourage them to suggest alternatives, too.

Send developers of legacy extensions messages asking them if they plan to migrate their extension. As the release date nears, every extension on addons.mozilla.org can be put into one of three categories:

“WebExtension ready” – either the current version is a WebExtension, or one with slightly reduced features will be installed automatically when Quantum ships

“WebExtension in development” – either there is a pre-release version uploaded already, or the author has confirmed that they are working on one in private

“No WebExtension planned” – the author has not responded, has said that they are not interested in a rewrite, or there’s no prospect of necessary APIs being added

Launch an Adopt an Extension program. If an extension is marked as abandoned, let someone offer to rewrite it as a WebExtension so the user doesn’t have to choose a replacement. Maybe only do this if the original author explicitly allows it, but make it easy for them to do so.

Build some mechanism for extensions to migrate another extensions settings (if that doesn’t already exist?). One of the most tedious parts of switching to an alternative extension is configuring it to work how you’re used to. Encourage developers to use it, reassure users they can take advantage of it.

Make it Mozilla’s Problem

A recurring response to complaints seems to be that it’s not up to Mozilla to make extensions work. Yet they continue to advertise extensions as a key feature of Firefox, so surely it is their problem to keep those extensions around.

Prioritise. Come up with some criteria and make a list of the extensions that absolutely must be ready before launch. Use this to guide the API development, the release scheduling, and the transition plans.

Do the work. If nobody steps forward to migrate a hugely popular extension, maybe Mozilla should work on it themselves. It may be that the original developer will be happy to maintain it once it’s working, but doesn’t have the resources for the necessary rewrite.

Hold User’s Hands

Warn people what’s coming. If you’re running Firefox 56 right now, you will see extensions in one click from the homepage that will not work as soon as you upgrade to Firefox 57. If an extension’s author has not said a WebExtension is coming, the listing should be downplayed, the warning impossible to ignore.

Build the alternatives into the UI. It baffles me that the official Extension Finder is a one-page app running off a spreadsheet, rather than part of addons.mozilla.org. If you land on a legacy extension, it should list WebExtension alternatives right there for you. If the Extension is marked as abandoned, show this right away, before Quantum is even released.

If the extension author has said there’s a new version in the works, tell users that. Once Quantum launches, show any alternatives which have been suggested as well, behind a link labelled “sorry, I can’t wait”.

Have a welcome screen showing which extensions have been disabled. I upgraded to Firefox 57, it told me how great it was, and my mouse gestures didn’t work any more. If I wasn’t aware of the change, it would have taken me some head-scratching to find out why and what to do about it.

2 thoughts on “How Mozilla completely dropped the ball with Quantum and WebExtensions”

Earlier this year they released the electrolysis project and there was a push for extension authors to upgrade their legacy extensions to be electrolysis compatible. That upgrade work is now useless and the extension authors need to rewrite them as web extensions. Why didn’t they push authors to move to web extensions when electrolysis was launched?

This whole thing is very saddening to me.
Good article, although I think Mozilla has done more than “drop the ball” on this development. They’re shooting their extension developers and entire userbase, especially the ones who want a sane, customizable Web browser in the fucking face!