New issue
Advanced search Search tips

Issue 606620 link

Starred by 3 users

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Blocking:
issue 521692



Sign in to add a comment

Need render pipeline throttling state replicated across iframe boundaries

Project Member Reported by esprehn@chromium.org, Apr 26 2016

Issue description

We're going to start throttling the rendering pipeline for iframes that are still loading their stylesheets. No iframe under a throttled iframe should ever run the pipeline either though which means if you have:

MainFrame
  \
  <iframe 1> OOPIF process 1
   \
    <iframe 2> OOPIF process 2

and <iframe 2> finishes loading its sheets, but <iframe 1> is still loading we should continue throttling the rendering pipeline for <iframe 2> until the parent frame finishes loading sheets and starts painting. Otherwise the nested iframe is pumping frames which are invisible, and we're breaking the invariant that if requestAnimationFrame is running, painting is happening.

I think there's some system for replicating bits across OOPIF processes used for things like the WebTreeScopeType bit. We probably need to use the same thing.

I assume the reason pipeline throttling works today for OOPIF is because we only throttle off screen iframes, so the state is implicitly replicated by the viewport and running the lifecycle throttling checks in every process.
 
Blocking: 521692
I believe your assumption is right: viewport visibility is implicitly replicated so OOPIF-throttling works. Propagating the throttling state explicitly sounds like a workable idea as long as the state is consistent by the time we actually do the lifecycle update (e.g., all children under a throttled parent are also throttled).

Comment 3 by tkent@chromium.org, Jun 23 2016

Components: -Blink>Architecture Blink>Internals
Renaming Blink>Architecture to Blink>Internals

Comment 4 by dcheng@chromium.org, Nov 19 2016

Cc: kenrb@chromium.org lfg@chromium.org
Labels: -Pri-3 Pri-2
Status: Available (was: Untriaged)
We also throttle now if the frame is still loading stylesheets, so we'll need to fix this now. We'll have to be careful about how we do this, since we want to make sure the viewport visibility and any other bits about throttling don't conflict somehow.

(We'll also need to do something once iframe display:none suppress layout boxes)
FYI, rendering pipeline throttling has been refactored to use IntersectionObserver so the viewport visibility trick no longer works over OOPIF.

I think to fix this we'd need to make it possible for <iframe 1> in Elliott's diagram to register an IntersectionObserver for its owning element in the main frame, and the same for <frame 2> in <frame 1>.

Comment 6 by dcheng@chromium.org, Nov 21 2016

I don't think IntersectionObserver will take into account the stylesheet throttling though, right? If we need a separate path for handling that, we may as well just use the same path consistently.
Ah right, I think stylesheet throttling takes precedence over visibility-based throttling.
Cc: slangley@chromium.org
Components: -Blink>Internals Blink>Internals>Frames
What's the status of this? We want to remove the old FOUC system, but it'll start making OOPIFs FOUC.

Ideally the subframeThrottled bit would be replicated so the parent frame would correctly block rendering on subframes during loading.
Project Member

Comment 9 by sheriffbot@chromium.org, Apr 13 2018

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
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.

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

Sign in to add a comment