WebExtensions are multiprocess-compatible by design, but so are Jetpack SDK extensions unless they use certain APIs. The main rationale for WebExtensions was to make it easier for extensions to support multiple browsers -- implicitly, because new extensions were increasingly Chrome-first or Chrome-only.[1]

The problem is less the end goal and more how Mozilla is handling the transition. Developers have identified missing APIs, but they don't know when or if they'll be implemented.

Option D: Define "good enough" in terms of specific features. Tell developers they'll have six months after that to migrate. Put out an ESR that fully supports both old and new APIs to give users a smooth transition. If you don't have the resources to do that, explain the tradeoffs in detail and apologize profusely.

[1] https://blog.mozilla.org/addons/2015/08/21/the-future-of-dev...

Thanks for the lengthy explanation, but my impression is that most people's assessments in here are of the form "Firefox is slow, but it has better addons". The choice you present therefore actually boils down to

A) Continue being slow and have better addons;

B) Become fast at the expense of worse addons (probably worse than Chrome rather than merely the same, as more users generally means more developers).

Is it really sensible for FF to give up its advantage with the stable minority of users who care about addons enough that they would weigh FF's addon advantage higher than its speed deficit and try to beat Chrome on its home field? Certainly, other FOSS projects that tried to do similar things (Gnome 3) have only managed to garner vitriol in exchange for no meaningful increase in adoption.

It's also worth keeping in mind if you hope for FF to compete with Chrome over users with the same value function that especially in the US, there are now many websites that actually only have been tested with Chrome and perhaps Safari and IE, and hence are broken in Firefox.

> Is it really sensible for FF to give up its advantage...?

That's the bet-the-company question, isn't it? Only history will tell, but I think the judgement of Mozilla in this matter is better than that of the commenters on this website, who have less data, represent a minority of users, and are prone to complaining.

What evidence, short of Mozilla going ahead with it and Firefox market share tanking over the course of a few months, would be sufficient to persuade you that this is a bad move?

(I do imagine that there should at least be ample precedent out there for the "management of ~10% market share company decides to sacrifice strong point of its own product to pursue the strong point of the market leader instead" pattern. I can think of several failed examples, but no successful ones - are there any? If not, I believe that should count as evidence that this is a common bias in company judgement.)

Market data from a reputable source, preferably one with extensive experience in the browser market, showing:

a) Favoring extensions over browsing experience (rendering speed, jank, etc) is likely to improve Mozilla's market share.

b) Market-relevant extensions are not going to be ported to WebExtensions.

Speculation and personal preference is not persuasive.

Regarding b): at least the author of DownThemAll!, which has ~1.2m users per [1] (which makes it the non-adblocker plugin with the highest number of users I can find), has come out saying they won't [2].

...and regarding a), I don't think that's all there is - FOSS projects at this point have a quite long track record of changes that were championed by the marketing crowd over the skepticism and outright opposition of the "fanatic techies" of the kind found here, such as KDE's Plasma Mobile and Mozilla's own phone OS, which turned out dead in the water exactly as the "unrepresentative" crowd expected.

[1] https://addons.mozilla.org/en-us/firefox/addon/downthemall/

[2] https://mail.mozilla.org/pipermail/dev-addons/2016-December/...

> I think the judgement of Mozilla in this matter is better than that of the commenters on this website, who have less data, represent a minority of users, and are prone to complaining.

This is the same as saying, "The judgment of the company is better than the judgment of their customers who say they will stop using their product if the company follows through on their plans."

This seems to have been poorly communicated by the Mozilla team and it is a shame bevause e10s is a a real improvement

See, I don't think it was poorly communicated by the Mozilla team. I've been reading their volunteer emails and their public facing blogs, and seeing their commentary on e10s all along.

What HAS been a problem is that they keep pushing it back because they don't want to upset the applecart of the legacy apps, and thus, e10s has basically become stalled by fear. And they didn't really do much to push back on that until very recently.

I think the main problem is, people look at e10s refactoring for their extensions, and thought it would never need to happen. That Mozilla would always just offer a 'back door' for them. I think that the XUL heavy extensions thought the same thing. The problem is, those two areas are the areas where a lot of the instability and issues come from, and the only way to solve those issues is to excise the code completely.

Mozilla's problem isn't communication. It's that people never seem to believe them, and they kept pushing it back.

Again, this is not accurate.

1. Developers are lazy. This includes addon developers. Until there is a concrete time that their existing code will stop working, there's little incentive for them to bother rewriting their code.

2. For extensions which require non-existent WebExtensions APIs, there is nothing they can do but hope and pray that Mozilla will deign to make such APIs to enable them to rewrite their whole codebase to use them. If Mozilla declines, then the addon author can do nothing except watch their extension die.

It is not a matter of addon authors not believing Mozilla. The ball is in Mozilla's court to follow through and enable the extension authors.

Now Mozilla has set themselves an arbitrary deadline to disable XUL, using the excuse that e10s and other XUL-breaking stuff will arrive on that deadline--which is another arbitrary deadline that they set. Is there a term for this kind of internal self-buck-passing?

They originally announced this plan, along with the reasons, in August 2015:

https://blog.mozilla.org/addons/2015/08/21/the-future-of-dev...

> This is because Firefox's UI uses the same single-threaded JavaScript engine that web pages do.

JavaScript contexts are single threaded, but even in a single process you can (and do) give separate web pages their own JavaScript contexts and run them in separate threads.