New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 780081 link

Starred by 2 users

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 2
Type: Bug



Sign in to add a comment

In session restore, prioritize OOPIFs in foreground tab over background processes

Project Member Reported by creis@chromium.org, Oct 31 2017

Issue description

During a recent field trial of --site-per-process (in  issue 760778 ), we observed a regression in the SessionRestore.ForegroundTabFirstLoaded UMA metric.  We suspect that the foreground main frame process is being prioritized over background processes, but this is probably not true for OOPIFs on the foreground tab.  It's likely this could lead to a later load stop event.

We should likely prioritize the process(es) of any OOPIFs on the foreground tab as well.
 

Comment 1 by creis@chromium.org, Oct 31 2017

Blocking: 780133

Comment 2 by creis@chromium.org, Nov 2 2017

Cc: gab@chromium.org
chrisha@ mentioned that we might not have prioritization of the foreground main frame process today?  gab@, do you know if there's anything making that tab load faster than background tabs today?

Comment 3 by creis@chromium.org, Nov 21 2017

Cc: oysteine@chromium.org
Owner: oysteine@chromium.org
oysteine@: gab@ mentioned that you're working on lowering process priority of renderers for solely invisible widgets.  Is there a bug for that?  I'm wondering if this can be marked as a duplicate, assuming that your change will cover the case of invisible OOPIF widgets as well as invisible main frame widgets.

(That way, visible OOPIFs will stay at normal priority, along with visible main frames.)

If that work will be ready soon, we could try to schedule our trial in issue 780133 to include it, but otherwise we can proceed without it.

Comment 4 by oysteine@google.com, Nov 21 2017

#3: The bug is https://bugs.chromium.org/p/chromium/issues/detail?id=560446 and the CL is https://chromium-review.googlesource.com/c/chromium/src/+/754299

It's not a complete fix (for now) and there's edge-cases where it'll fail (process-sharing will mean some background frames will still be set with foreground priority).

It *should* help with the session restore OOPIF case though, I think? As the CL will cause more renderer processes to get background priority set.

Comment 5 by creis@chromium.org, Nov 21 2017

Thanks!  At a high level it should help with OOPIFs, though I have some questions about the pending_views_ part.  I'll post a comment to the CL in a minute.  Glad to hear we're making progress on it, though!
Cc: csharrison@chromium.org bmcquade@chromium.org
<adding more page load metrics folks to CC>

The plan from #c3 to #c5 SGTM for addressing the SessionRestore.*Foreground*TabFirstLoaded regression, but I wonder if in the long-term we might also want to apply different process priority to 1) foreground main frame VS 2) foreground OOPIFs.  It seems to me that such differentiation might help with metrics like PageLoad.Experimental.PaintTiming.NavigationToFirstMeaningfulPaint (which AFAIU track only the painting/layout of the *main frame*).  OTOH, I understand that NavigationToFirstMeaningfulPaint considerations maybe be postponed and/or treated as a separate bug.

QUESTION: do we want to open a NavigationToFirstMeaningfulPaint-focused bug now or do we want to wait until OOPIFs trials gather enough data to see a statistically significant impact on NavigationToFirstMeaningfulPaint and similar metrics?

Comment 7 by creis@chromium.org, Nov 28 2017

Blocking: -780133
Owner: ----

Sign in to add a comment