Today sees the official release of Firefox 57, also known as “Project Quantum”, a major rewrite of key parts of the browser. With it comes a new, incompatible, extensions API, and I (mostly) understand why. But on launch day, users will find about 3 in 4 extensions simply don’t work, and Mozilla’s planning for this seems to have been nothing short of incompetent. Rather than just whinging, I want to throw out some ideas of how they should have tried harder.

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.

As far as I know, this feature works off the same list as the very fancy-looking “Extension Finder tool”. It turns out, this data is maintained, by hand, in a spreadsheet, which lists a grand total of 75 extensions; that’s one in every two hundred listed on addons.mozilla.org. These are paired one-to-one with web extensions based almost entirely on suggestions submitted to a forum thread confusingly titled “Favourite WebExtensions?”

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.

Crowdsource All the Things

• This was the headline of a bug I raised on the Github project of the Extension Finder tool. It fell on deaf ears; maybe I wasn’t speaking to the right person, but there didn’t seem any enthusiasm for finding out who that right person was.
• 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.
• Don’t duplicate effort. There’s actually another spreadsheet from a different Mozilla team, as well as the aforementioned arewewebextensionsyet.com. Nobody seems to have suggested these people talk to each other.

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.