Multiprocess Firefox [e10s] (Partial Release: Fx48)

[smsmith]

Wow. That thing was crash city.

[Omega X]

Most of the crashes seems to come from the Layers API.

[winapp2]

Haha, I experienced a lot of crashes too (albeit without safemode)

Middle clicking a bookmark toolbar item caused a crash, and I didn't get much farther than that

[orizng]

Not possible. *MANY* XPI extensions directly manipulate the DOM of websites, or fetch data from the web, and manipulate the interface simultaneously. Also, the way that XPI extensions are loaded into Firefox... they are actually loaded as PART OF the interface.

If thats the case, they need to balance the benefit of multi-process against loss of functions.

If Firefox has stayed responsive and secure w/o multi-process, there is at least no urgency to push this through at great costs.

[SnoutSpout]

If thats the case, they need to balance the benefit of multi-process against loss of functions.

If Firefox has stayed responsive and secure w/o multi-process, there is at least no urgency to push this through at great costs.

I doubt Google, when starting with a blank slate, put a lot of thought into the cost-benefit analysis as compared to having a more monolithic browser. Using a multiprocess model where content is compartmentalized probably makes things easier to debug (and optimize for), especially if you have an extension system that is more limited in what it can do.

It's hard to use telemetry to gauge such a thing as responsiveness. Not only does the tolerance threshold varies from person to person, it depends greatly on the user's machine specs, what is in his profile, things like the sessionstore data, what addons are being used etc. All we're left with are simply guesses based on the anecdotal cases we've seen or heard about.

If we're just simply talking about addons then the more important question is: in what state will the post-e10s addon be in? If the functionality is reduced then it really boils down to what the user thinks is important for a Firefox browser to have. If more users think the sacrifice is worth it (and that's the scenario Mozilla is hoping for) as opposed to those who don't, then it's a win in Mozilla's book as it would simplify their lives greatly if addons were reduced in functionality/impact over the main browser. That's probably the worst case scenario though.

At the end of the day it's simply a matter of tradeoffs. Chrome users will tell you the browser is getting more resource-heavy, not less, over time. You simply select the system where your tradeoff generates the most utility for the userbase and that userbase has different priorities from browser to browser.

[patrickjdempsey]

If we're just simply talking about addons then the more important question is: in what state will the post-e10s addon be in? If the functionality is reduced then it really boils down to what the user thinks is important for a Firefox browser to have.

It's not a question of "reduced functionality" in addons. Extensions that talk to websites will be broken until fixed by the author or unless Mozilla can come up with some magic that just makes them work even though they should be broken. There will be errors, possibly error messages, and possibly even crashing. Mozilla is notorious for assuming that the addons-author community are all wiz-kids who can easily fix anything that Mozilla breaks. The reality is that 4 or 5 years ago Extensions could be built by anyone with a basic knowledge of JavaScript and enough understanding of HTML to be able to transfer that knowledge to XUL, and now it requires a degree in programming JS and JQuery and Mozilla's internal APIs. Quality has gone up, but many classic OLD extensions people loved would just never make the cut today.

An example of something which will likely be broken on release day is RoboForm... those guys can't even keep on top of releases that don't have any changes that impact them... and it's all about form injection.

[iwod]

Yes, this begs the question of why then didn't Mozilla decided to break the extensions compatibility then and move on with e10s two and half years ago.

[Drumbrake]

Because they're not that dumb after all,and knew that Australis alone would be provoking enough of a stir,no need to break even more stuff(which is incidentally the stuff that,for the most part,makes Firefox so great,i.e. addons)?

[patrickjdempsey]

Yes, this begs the question of why then didn't Mozilla decided to break the extensions compatibility then and move on with e10s two and half years ago.

Because it's taken this long to get it far enough along that it only crashes severely every 2 minutes?

[Omega X]

It never used to crash so easily in the past. Whatever happened to Layers is causing all kinds of hurt when its on.
https://bugzilla.mozilla.org/show_bug.cgi?id=947213

[SnoutSpout]

Because it's taken this long to get it far enough along that it only crashes severely every 2 minutes?

TBF, they've put it on the backburner for nearly a year to "concentrate" on Snappy (well we know how that went.) Still, I can easily see e10s being as protracted a development process as 4.0, if only because the testing cycle can easily overrun development time. I wonder how many Nightly testers are willing to take the dip testing the builds without any extensions.

[avada]

Wow. That thing was crash city.

Two out of eight times times it ran more than 60 seconds before a crash.

[flaneurb]

I tried e10 for a few minutes with a clean profile. There were no crashes in that time but the CPU usage appeared higher on "normal" tabs and much higher for a tab playing a YouTube video when compared to the CPU usage on the same machine but without browser.tabs.remote set to true. My laptop is an oldish one with integrated graphics and 4 GB RAM.

[Omega X]

It seems to be crashing less now. I can access the Australocalypse Menu without crashing. Bookmarks menu still wigs out though.

[Caspid]

I had a lot of assumptions/misconceptions about multiple processes (based largely on experience with Google Chrome), but that article in the op helped to correct/alleviate most of my concerns. Mostly, I hope the promise of additional performance, improved stability (Chrome's multiprocess architecture purportedly affords greater stability, but in my experience, the whole browser is prone to crashing), and minimal additional resource expenditure (unlike Chrome's increasing bloatedness) holds up.