It's back. Sorry - but I hope you know who have turned this back on.

Ignore comment 1 (not sure what I've meant there)

pawliger@ is probably no longer the right owner.

There was a lot of effort put into making tab restore in Chrome OS not bring the machine to its knees.  If this has stopped working it's a pretty major regression.

warx@ can you investigate what's going on here?  Reach out to skuhne@ to get an understanding of how this is supposed to work.

Sure.

Any update on this? We are nearing stable for 55 and this is marked as a blocker.

I've seen situations similar to this, but they're due to a case we've never explicitly tried to handle:

(1) A complicated site like inbox/gmail/drive starts loading.
(2) It loads a very lightweight "loader" page, which immediately fires off a "done loading" event.
(3) TabLoader starts loading other tabs.
(4) Meanwhile, the complicated tab actually just started loading, and is now retrieving the bulk of its resources.

The TabLoader is intended to keep no more than 2 tabs loading at a time, but when you have N tabs that use "loaders", you end up with N + 2 loading tabs. Even worse is the fact that these tabs are the biggest and most resource hungry.

SessionRestore/TabLoader was never designed to handle this situation. And there's no easy fix without a *lot* of effort. We could hack in mechanisms for detecting continued loading/quiescence/special cases for certain sites, but these are all hacks. The right long term situation is to integrate scheduling + priorities into the network stack, which is something that's not going to happen until mid- to late-2017.

skuhne: Does this describe what you are seeing?

Could very well be:

I have mostly documents, gmail, buganizer, calendar, etc. pages.

All of these types load first the small loader and then the rest.
Note: I guess that is the default for nearly all Google pages...

skuhne@, could you help check when it happens, does memory pressure ever hit high?

If this is a long term issue, could we remove M-55 RBS?

When it happens the system becomes pretty much unresponsive and there isn't a chance to do anything...
(in fact I tried already to see what is going on, but ... well with the system showing rotating spinners and not reacting to anything else...)

This in itself indicates a memory problem - but - I am using an 8GB (or 16?) Samus - so somehow I doubt that we are running out of memory.
Also - I am fairly certatain that I was checking the memory / tab discarder stat page and it didn't show anything suspicious after it was done.

BUT I will do that again when I see it again. 

Per comment 13 proactively removing RBS. 

We are nearing 55 stable, if we can get a fix in the next two days we can make the targeted RC, if not we would have to punt or delay anyway. 

To summarize:

It sounds like we think the tab restoration optimization IS still working, but sites with a loader page make it ineffective.  Correct?

If that's the case, I agree with removing RBS but we do need to still figure out a solution.

I am seeing this issue too in Chrome 54 stable on macOS. I killed and restarted Chrome to try and recover from https://bugs.chromium.org/p/chromium/issues/detail?id=670485. I had several windows open, with several tabs each. Chrome seems to be loading all tabs, even background tabs in background windows, and the active tab in the frontmost window is unusable until everything is done loading.

I am not sure if this affect *all* tabs, but in my case the frontmost tab was the Google bug tracker, and the worst offenders of the background tabs were Google Docs and Spreadsheets documents. In fact, after a while I got the "tabs frozen" messages for a couple of processes consisting entirely of Docs/Spreadsheets tabs, and I ended up killing them to finally get Chrome to be usable.

warx: This seems pretty major; I thought we were supposed to start newly-restored-on-foreground tabs in pre-Discard'ed mode and then nudge them to load once the system looks happy?

Loading JS-intensive tabs (e.g. Google Docs, Gmail) on startup brings CPU utilization to 100% very quickly, while RAM usage ramps up. What I do is run https://github.com/sindresorhus/kill-tabs in a while loop until all loading tabs are killed. Brutal, but does the job.

Regarding comment 18:

The logic is still there to do this gracefully, unfortunately the "done" signal that is used is way too primitive, and fails terribly with modern web apps. Everybody uses a lightweight loader, which then does the heavy network and JS stuff after the initial "loader" load has completed.

Work is under way to use CPU + network quiescence of a page as a measure of "doneness" of loading. Passing to panicker@ to assign to the best owner, as she's driving that effort.

We think that crbug.com/723233 would also possibly mitigate this.