1191440 - e10s crashes unloaded tabs

Status: RESOLVED WORKSFORME

(Firefox :: Untriaged, defect)

Description

[Aeed]

User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0
Build ID: 20150805030208

Steps to reproduce:

Browsing with dom.ipc.processCount=3 with multiple tabs, some loaded, most unloaded. Hardware acceleration disabled.


Actual results:

Browser remained stable, but multiple tabs crashed simultaneously. A number of loaded tabs crashed, but a large number of unloaded tabs also crashed.


Expected results:

It should not be possible for unloaded tabs to crash, no resources should be being allocated to the unloaded tabs. This brings to mind the fact that Firefox becomes progressively slower at startup with hundreds of unloaded tabs. This should not occur as no resources whatsoever should be going to those unloaded tabs, except retaining 1. the current URL, 2 the location on the webpage if closing Firefox on the previous session while scrolled halfway down the page etc., and 3. back/forwards history for that tab.

Clearly additional resources are being allocated to unloaded tabs, which apart from making the entire browser bloated and laggy with hundreds of unloaded tabs, also causes unloaded tabs to crash at times.

Comment 1

[Brad Lassey [:blassey] (use needinfo?)]

Phillip, this is really about our UX treatment for unrestored tabs. Should we treat them as crashed when the content process crashes, or just leave them in the unrestored state?

Comment 2

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

Good point! The fact that all tabs show the crash icon is indeed reflecting the implementation rather than the mental model.

Can we be sure which tab has crashed and then only show the notification on that tab?
When the user switches to a different tab, it would just reload...

Comment 3

[Mike Conley (:mconley) (:⚙️)]

Hey phlsa,

Thanks! Would you consider this issue important enough to block release e10s on, or is this more of a "wicked UX win if we fix it"? Or somewhere in between? :D

Comment 4

[Aeed]

Hi guys

Not sure if my opinion counts, but I don't think it's something that I'd consider a release blocker. However do consider what was mentioned in the OP regarding unloaded tabs retaining excess data; unloaded tabs should retain as little data as possible to preserve browser speed/responsiveness.

I could be wrong, but it sounds like you're discussing 'switching off the warning light' rather than 'filling up the car's oil' to resolve the problem.

Comment 5

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

I don't think it's a blocker, but definitely a UX win.
I would also assume that we reduce the number of crashes significantly before we ship e10s (currently crashes multiple times a day for me)

Aeed, the warning light analogy is a bit off since the problem would fix itself when switching to a background tab that needs to reload because of a content crash.

Comment 7

[Mike Hommey [:glandium]]

(In reply to Philipp Sackl [:phlsa] (Firefox UX) please use needinfo from comment #5)
> I don't think it's a blocker, but definitely a UX win.

Considering bug 1204774 and the massive amount of memory suckage this incurs, this should probably be a blocker.

Comment 8

[Andrew McCreight [:mccr8]]

There's certainly a UX issue here, wherein an unloaded page probably did not really crash so it is weird to see the UI when you switch to it, but as glandium points in bug 1204774 out there is also a memory issue, where it sounds like that when an unloaded page (that had about:blank) is restored after a crash it is replaced with about:tabcrashed, and about:tabcrashed uses more memory than about:blank.

I could imagine a scenario where a user on a 32-bit system has a large number of unrestored tabs which is getting close to their memory limit, but isn't quite there, then whatever active page they are on crashes for some unrelated reason, then you end up with all of your unloaded tabs using more memory, which prevents you from doing anything.

It seems like the lazy loading that is being done for regular tabs needs to be extended to crashed tabs, so that about:tabcrashed does not load for a tab until somebody switches to the tab.

Comment 9

[Nicholas Nethercote [inactive]]

Is this fixed by bug 1209689, or this more work required here?

Comment 10

[Mike Conley (:mconley) (:⚙️)]

Yeah, this is fixed by bug 1209689.