Update on Multi-process Firefox (Electrolysis) Development
On Nov. 4, 2011, we held a public call to evaluate options for improving Firefox responsiveness including the multi-process Firefox initiative (code name Electrolysis, also known as e10s). The outcome of this discussion was a decision to put the Electrolysis initiative on hold for the foreseeable future and focus on other initiatives aimed at improving responsiveness in the browser. As the Electrolysis program manager I would like to share the background around this decision.
The goal of Electrolysis is to separate the user interface process from the content processes (the portion of the browser that renders Web pages for display) with an aim to improve responsiveness in the user interface. There are a number of secondary program goals such as crash protection, support for multi-core machines, and sandboxing (isolating) content to improve security. (See Chris Blizzard’s goals for multi-process Firefox blog post for more details about the goals.) All of these items have technical merit and it was not the technical merit of the initiative that was under review.
Electrolysis is a huge undertaking. I can’t emphasize that point enough. Converting an established product, like Firefox, from a single- to multi-process architecture requires the involvement and coordination of many teams. Most recently I have been working with the accessibility, add-ons, front-end, graphics, and release engineering teams on various projects. Electrolysis requires a large investment of resources and time and has a long timeline for completion. How long? At this point we do not have a definitive answer as there are many unknowns that need to be investigated and addressed, such as how to ensure that add-ons can function in this new multi-process environment.
The list of responsiveness initiatives includes a number of smaller initiatives, such as out of process plug-ins (OOPP), Places-optimization, and incremental garbage collection. When looking at the investment in Electrolysis, it is quickly apparent that the talented people working on this program could instead be working on some of these smaller initiatives. We reviewed a short list of these initiatives and concluded that the results of working on the short term initiatives should provide significant responsiveness wins delivered in a shorter (known) time frame than Electrolysis. This means a more responsive Firefox will be available on your desktop sooner.
42 Responses to Update on Multi-process Firefox (Electrolysis) Development
This is actually the best news I heard at the MozCamp. While I see why Mozilla was working on e10s and how this undertaking has its merits, the prospect of having to support e10s in Adblock Plus on the desktop Firefox was giving me nightmares ever since we added support for multi-process Fennec. It is hard to throw away something that you’ve put much work into but in this case it is probably for the best.
In terms of choosing “e10s enabled firefox without AdBlock” and “Old sluggish Firefox with Adblock” what do you think we choose? Of course e10sFirefox with NoScript! NoScript cut enough ads already.
they never said it was thrown away, much of the core work that was laying the framework for Electrolysis is still going to land at some point.
really nice news….
Other major Browser have multi-process, Firefox doesn’t need it, because Firefox user can live with freezing UI….
@Anubis
The article states that there are viable alternatives to lessen the interface freezes which can be released to end users far earlier than Electrolysis. And it’s not like separating chrome and content is a silver bullet against either. I can reliably cause Chrome’s interface to stall by simply opening enough background tabs in parallel as there are apparently still some bottle-necks left in the browser process.
This news will need some very good PR work otherwise the press will rip you apart though.
So basically. You’re not going to do implement multi-process architecture because it requires hacking on a established code base that can’t handle such a massive architectural change without breaking a major product and pissing off millions of existing users. Yeah, I had a feeling Electrolysis was too ambitious to be more than vaporware.
This worries me. If Adblock Plus, one of the most actively-maintained extensions, is having “nightmares” coping with e10s, I wonder how well other extensions will fare.
I’m also a bit disturbed by the decision to indefinitely ignore long-term goals, in favor of short-term goals. Yes, I’m aware that Mozilla lacks the resources that Microsoft and Google have to allow the juggling of multiple goals at once, but given how there doesn’t even seem to be any concrete plans of picking e10s up again, it makes one wonder whether Mozilla is committed to the long haul, or whether it has enough vision to do so.
Hmm..good and bad….if a tab consumed more resources…we dont know…kill whole FF. often happens with me…dont know if e10e was solution.
As far as I could deduce from the discussions on Bugzilla and in the news groups the work they intend to prioritize is complementary to Electrolysis and not intended to replace it. For instance, IIRC access to the Places database (storing history, bookmarks and favicons) happens in the browser process irrespective of the content/chrome separation so making it completely asynchronous would have to be done anyway to avoid blocking the main thread and thus the UI. Same applies to other APIs which can’t or won’t be moved to their own processes.
@jrbrusseau
> Yeah, I had a feeling Electrolysis was too ambitious to be more than vaporware.
Firefox mobile shipped with e10s, so it is definitely not vaporware in general. But on desktop it has been harder than expected, yes.
I think Mozilla could, if it wanted to, release a desktop Firefox with e10s pretty soon, *without* addons, developer tools, and a few other things. Because all the basic stuff like showing web pages works on Firefox mobile – which can be run on desktop machines. The code works. However, that would be a very bad idea obviously, it would be Gecko but not really Firefox.
As someone that did a lot of work on e10s, it’s disappointing to see it not focused on. But the logic makes sense: There are quicker ways to get responsiveness improvements without the difficulties of e10s, and it makes sense to focus on them. This is the right decision I think.
Lettuce bee cereal, multi-process FIrefox will never happen.
Many responders seem to infer from the article that e10s will “never” happen. What I read is that it won’t happen this week. Maybe not even this year. But never? I bet it will happen before I die, and I’ll be 61 years old in January.
Pingback: Firefox not to become fully multiprocess in the near future • Mozilla Links
Quitters never win.
You guys will lose market share by the end of next month to Chrome. It is a critical time for Mozilla. Now is the time to be ambitious. This is a sad development actually. The more you delay with your improvements just because it is complex, the more Chrome is going to run away with your share of the cake.
Something to think about!
That’s what the Russians said about their Moon Mission in the 60′s .. and look where it got them ..
Pingback: Firefox отказывается в обозримом будущем от перехода на многопроцессную модель
Pingback: Firefox no será multiproceso por el momento » SupporTedia
Pingback: Firefox no será multiproceso por el momento - La Isla Buscada
wrong move, i waited enough, i’m moving to a better alternative now = Chrome
Pingback: Новости компьютерного мира - Firefox отказывается в обозримом будущем от перехода на многопроцессную модель
Pingback: Firefox no será multiproceso por el momento | EmaCorp News
Pingback: Si la vida fuera justa dejaría de llamarse vida » Firefox no será multiproceso por el momento
This is very disappointing news, Firefox has serious performance problems and with CPUs all being multi-core & hyper-threaded now a days, multi-process is the future. If Chrome ever improves it’s add-on extensibility, then I’m gone and I’ll never look back at FF.
What about multi-threaded Firefox?
Firefox IS multithreaded
At least Mozz should think about UI in a separate thread.
Its XXI but user still cant access UI when something is loading.
Pingback: Firefox no será multiproceso por el momento | R-NET
Pingback: Firefox no será multiproceso por el momento « ΔΠҜ ÛяǾ฿ØЯø
Pingback: Firefox no será multiproceso por el momento | Jobbr es
It may be time to start from scratch and create a successor to Firefox, as Firefox was t