5 ms·

Okay, I read through the entire comment tree and I didn't see a single top-level comment explaining why they're doing this. So I'm going to give it a shot. If

Okay, I read through the entire comment tree and I didn't see a single top-level comment explaining why they're doing this. So I'm going to give it a shot. If you don't run an ad-blocker, and you go to a typical commercial web site (say, nytimes.com), Firefox can be incredibly slow and laggy. Scrolling is janky and the whole experience is just bad. The whole browser can lock up. This is because Firefox's UI uses the same single-threaded JavaScript engine that web pages do. Ads tend not to be good web citizens, so they cause that single-threaded engine to run poorly, which causes the whole browser, even UI elements like scrolling, to run poorly. To fix this, Firefox has moved to a multi-process model. I believe it's called Electrolysis (e10s). The UI uses a different JavaScript process than web pages. Electrolysis is enabled today. And yet, if you read the comments in this thread, you'll see a lot of people complaining about Firefox being slow and janky. What's up with that? Electrolysis was supposed to fix it! Well, legacy extensions dig into the internals of Firefox. If you've built multi-process code, you know that it's very sensitive to race conditions. Third-party extensions running arbitrary code make it impossible, or at least prohibitively difficult, for Firefox to run e10s. So e10s is disabled if you have a legacy extension. This causes Firefox to be slow and janky. To fix this problem, Firefox is removing support for legacy extensions. To be clear, the engineering tradeoff being made here is this: A) Allow legacy extensions to run arbitrary code. See performance get steadily worse in comparison to other browsers. B) Have a fast, smooth, multi-process browser. Hope that the new extension mechanism is "good enough" and that important extensions are migrated. You can't have both. Mozilla has chosen B). You may disagree with this choice. Personally, I think it was the right one. (You might say that the correct answer is C) run single-threaded when legacy extensions exist, and e10s otherwise. This is the situation that exists today. Look at all the people complaining about Firefox's performance. I don't think this is a viable solution, as people blame Firefox even when it's their extensions that are to blame. Also, option B) gives extension developers a reason to migrate and help Mozilla identify needed APIs.) Apologies if I got some of these details wrong. I've been following Firefox's migration to a multiprocess model with interest, but I'm hardly an expert.

Royalaid 10y ago
This seems to have been poorly communicated by the Mozilla team and it is a shame bevause e10s is a a real improvement
- GraemeLion 10y ago
  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.
  - alphapapa 10y ago
    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?
- jdlshore 10y ago
  They originally announced this plan, along with the reasons, in August 2015: https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/ https://blog.mozilla.org/addons/2015/08/21/the-future-of-dev...
4bpp 10y ago
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.
- jdlshore 10y ago
  > 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.
  - 4bpp 10y ago
    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.)
    - jdlshore 10y ago
pseudalopex 10y ago
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-developing-firefox-add-ons/ https://blog.mozilla.org/addons/2015/08/21/the-future-of-dev...
saurik 10y ago
> 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.

Royalaid 10y ago

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

GraemeLion 10y ago
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.
- alphapapa 10y ago
  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?
jdlshore 10y ago
They originally announced this plan, along with the reasons, in August 2015: https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/ https://blog.mozilla.org/addons/2015/08/21/the-future-of-dev...

4bpp 10y ago

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.

jdlshore 10y ago
> 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.
- 4bpp 10y ago
  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.)
  - jdlshore 10y ago

pseudalopex 10y ago

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-developing-firefox-add-ons/ https://blog.mozilla.org/addons/2015/08/21/the-future-of-dev...

saurik 10y ago

> 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.