For some background, see  bug 560446 . The tl;dr is that we currently don't set the process priority of fresh renderers because we they might not have any render widgets at that point and would end up getting background priority. Initial visibility is broken for similar reasons AFAIU.

I wonder if the Global Tab Coordinator will be in a better position to fix this, since in theory it can keep track of the fact that the new renderer was spawned in response to a navigation.

Re #1: Sounds reasonable.

We also talked about a more near term workaround where we have a ~10 second grace period before we apply throttling based on a visibility change (which will be useful for other reasons too).

The challenge is to solve this in a way that doesn't harm the browser restore case. In that case we have, let's say, twenty tabs all trying to be restored simultaneously and we want the visible one to run at full priority while all of the others run at lower priority with throttled timers.

It seems like the correct solution is to count a newly spawned renderer as visible if the tab that it will show up in is visible. I don't know what is involved in making this work.

Agreed. I think we need the global tab coordinator in place before we can do prioritization like that.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This is effectively a duplicate of  bug 560446 . I'm going to close it as such and annotate that bug to remind those working on it of this aspect of the issue.