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