Adding multi-process to a large project that was not designed for multi-process is an astronomical amount of work. And Firefox's approach has advantages over Chrome's, so they're not simply playing catch-up.
Chrome is utterly unsuited to the use case of leaving hundreds of tabs open, which happens often to me, as I only bother updating/cleaning my bookmarks a couple of times a year. There's three main issues with Chrome:
1) Nothing I've found that works nearly as well as Tree Style Tab.
2) Chrome always reloads all tabs when the browser starts up. Firefox, at least with Session Manager, will only load old tabs when I activate them.
3) Chrome takes up way more memory. That's partly due to #2, but partly inherent in the multi-process model.
The Chrome UI also gets weird under load. With Firefox, it's easy to tell when it's laggy. With Chrome, the UI seems asynchronous, but there's no consideration for actions taking a long time, so you can get the annoying feeling of clicking with nothing obvious happening.
Chrome chews through a lot of resources on my machine. Firefox is a lot lighter. And I think it will still be lighter since they're targeting a 2-process model instead of Chrome's (let me count) 17 that it just launched on startup.
Thank you! That makes sense, I still think I'd rather have per-tab isolation but I was genuinely interested in why FF would be preferable in this use-case.
Understood, but I'm speaking from the viewpoint of a user, here. It's a massive annoyance for a crashed tab to annihilate the other 49. (And the session restore being activated is generally grounds for a smoke break, because your system will be tied up for a while...)
Session restore in Firefox has been lazy for a long time now (the tab only loads when you activate it). It doesn't take longer than loading a single page.
How often do tabs crash for you? That's the real issue if you ask me. I'm on Nightly (with Electrolysis!) and the last crash was over 2 months ago.
Counter-anecdote: I use Firefox all day every day and usually have 100s of tabs open. I haven't had a legitimate full-browser crash in years. I've had a hang that resulted in me having to kill the process probably 3 times in the last year. I usually don't enable Flash, but when I do, it usually doesn't crash, and when it does, it just takes out all instances of Flash currently running; doesn't bring down the whole browser. I'm on Linux.
If you're getting a lot of Flash-induced crashing, you may want to check into alternate implementations of Flash, like Gnash, Lightspark, or even Mozilla's Shumway.
It shouldn't. At least on Windows I've gotten used to killing the plugin container about once ever 2 days.
Firefox itself crashes once per month, maybe less.
Firefox = rock solid. Flash = porous rock, at best :)
You should go to about:support and use Refresh Firefox which will probably fix most of your crashes (outside of Flash-related ones which should only be affecting the plugin and not the browser).
>It doesn't take longer than loading a single page.
Yeah, because it only loads a single page. It doesn't actually restore anything. Sometimes the pages it restores aren't even the live version but a cached one, I have no idea when or why it does that. It's absolutely infuriating.
Infuriating? It's one of the main reasons I've switched back to FF (that, and tab groups)! I didn't like have every single tab reload on restore as I don't need 90% of them until much later.
Speaking as a different user, one who looks at the task manager a decent amount, I really appreciate not having 49 different Firefox processes. This is definitely an issue of personal preference as it's been debated back and forth here a good amount, so no side is really "right" regarding single process v. multi process, but I'm firmly in the former camp.
Firefox multiprocess, by default, has just one process for all the tab content and one for the "chrome". You can increase the number of processes used for tab content manually in about:config.
Since 38a (previous nightly) electrolysis e10s is enable by defualt IIRC. That's the main reason I favor Firefox instead of Chromium these days, since I'd love to provide them with automatic user feedback as much as possible. Multithreading isolates from crashes half the time, but some times everything will go down. Also there seem to be concurrent issues and threading overhead, for mundane page loading can become very very sluggish.
I'd rather they make the code more robust to make crashes unlikely enough that they can actually debug and fix them when they occur, rather than going multi-process as a band aid to make recovery easier on a user
That said, it is easy to recover from simply by re-opening FF and you're right back where you were and I haven't had a total browser crash in a long time. I do experience lock up issues though
That was more directed at the F-ING SSL issue, but still, end of 2015 to have a feature that's considered standard nowadays and introduced 7 years ago?
How much of the work that went into deprecating certs and removing obscure command line flags and setting up HTTP/2 (which isn't even really used by anyone yet) could have went into electrolysis?
None of it. The work on multiprocess Firefox is primarily an issue in the front end UI code (written in JS), and does not have much to do with networking or crypto.
Another thing to keep in mind is that patch notes are a list of user-facing changes, not a breakdown of where the engineering effort went in a particular 5 week release cycle. Removing the command line flag probably took an engineer an hour or two to do. In the same time frame, I spent weeks analyzing and fixing a variety of leaks that only show up in multiprocess Firefox, but none of that shows up in the patch notes.
SPDY indicator[1] tells me that HTTP/2 is active on all Google properties, including YouTube. That's a nice chunk of the web right there.
I agree with you on older bugs just lingering around. This is a serious issue for many open source projects. JWZ was complaining about it years ago[2]. My favourite example is the problem of putting the tabs at the bottom of the window in gnome-terminal[3], which has been reported over 12 ago, has a patch available posted in the bugzilla, and it's still not fixed.
Chrome's first public release, which included multiprocess tabs, was on December 11, 2008. There has been more than enough time for Mozilla to catch up.
Note the words "first public release". Not to knock Chrome's achievements in this area, but it's an inescapable fact that they did not have any previous architecture to migrate from. Taking any nontrivial program that has had years to assume a single-process architecture, and updating it to work in a multiprocess manner, is hard. It takes time to do properly.
