+samans@. Thoughts? Could this be a frame eviction issue?

Probably not because the tab is visible. I've only seen this when the GPU process crashes.

A level 4 Screenshot appears! It attacks! Your Bug gains 1 Comment.

This morning I had Calendar and the Gerrit tab in the screenshot open in the topmost windows of each monitor, and both were blank black. Other windows on the two monitors, which were only partially visible behind the two topmost ones, were not blank.

Deleted: Screenshot 2018-08-10 at 09.54.58 - Display 1.png 19.1 KB

	Screenshot 2018-08-10 at 09.54.58 - Display 1.png 19.1 KB View Download

Just checked in chrome://inspect, to see whether the blank Calendar tab wakes up when I attach Dev Tools to it, and found that it isn't even listed in chrome://inspect (under Pages nor Apps).  Its process is listed in Task Manager, and regularly consumes CPU or network resources, just not in chrome://inspect.

Clicking to focus the Calendar tab causes it to spring to life, and immediately appear in chrome://inspect.

Re-assigning to ResourceCoordinator component, and to chrisha@, since this seems most likely an issue with the page lifecycle experiments.

Wez, can you open chrome://discards and find the row corresponding to that tab, and share its contents? That will tell us whether or not the resource coordinator has frozen the tab, and whether or not it thinks it is visible.

cc fdoray as owner of freezing logic

chrome://discards says the tab is visible, and was unloaded (see attached screenshot).

Deleted: Screenshot 2018-08-13 at 17.27.58 - Display 2.png 15.7 KB

	Screenshot 2018-08-13 at 17.27.58 - Display 2.png 15.7 KB View Download

The tab also has a non-zero discard count, which means that it looks like it's been deliberately discarded, either proactively or urgently (coming soon to you in chrome://discards, an indication of the discard reason!)

Discarding will happily discard occluded (but otherwise "active") tabs. They will only be reloaded when they actually receive input focus, and *not* when they simply become visible. This is to prevent all tabs from reloading when using expose mode to show all windows.

How is the window subsequently becoming visible? Is this a visible foreground window immediately after resume? One working hypothesis would be that when the machine goes to sleep all windows are told they are no longer visible, in which case we might think it's eligible for discarding.

Can you get the logs from the device? There's lots of information about discard decisions in there.

Re #7: Yes, I can get at the Chrome logs easily - will share them with you off-bug.  And yes, my guess would be that something about the suspend/resume cycle causes the windows to (perhaps briefly) believe they are not visible - in particular there are some quirks around monitor wake-up that might be related.

fdoray: We had a chat about this last week and you mentioned fixing the reload logic to *not* require focus, but only require visibility? Mind taking care of that?

This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this.