Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider improving interoperability of <iframe> throttling margins. #10333

Open
emilio opened this issue May 8, 2024 · 11 comments
Open

Consider improving interoperability of <iframe> throttling margins. #10333

emilio opened this issue May 8, 2024 · 11 comments

Comments

@emilio
Copy link
Contributor

emilio commented May 8, 2024

What is the issue with the HTML Standard?

My understanding is that all browsers implement some sort of throttling of offscreen / invisible iframes.

In Firefox, this is kind of messy, and differs between in-process and out-of-process iframes right now.

It seems according to @szager-chromium in Chromium there's no margin at all.

I think some things could probably be specified properly:

  • visibility: hidden / display: none should always be throttled.
  • Offscreen iframes should be throttled, with some UA-defined margin perhaps?

Are there other cases where UAs throttle iframes? cc @khushalsagar

@szager-chromium
Copy link

For reference, here is chromium's logic:

https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/frame/frame_view.cc;drc=4834462d69ddf6e0ac6b27572618e4436de4a2f3;l=317

Historically, we have also had one or two weird carve-outs for throttling logic that were driven by real-world usage; for example:

https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/frame/frame_view.cc;drc=4834462d69ddf6e0ac6b27572618e4436de4a2f3;l=279

A tighter spec with WPT would be great.

@khushalsagar
Copy link
Contributor

Other than the visibility based throttling @szager-chromium mentioned, content-visibility is the other reason I could find for it (@vmpstr for it). The throttling done for view transitions is already carved out separately.

@vmpstr
Copy link
Member

vmpstr commented May 13, 2024

c-v language is in https://www.w3.org/TR/css-contain-2/#cv-notes point number 7, but it's "should" language

@annevk
Copy link
Member

annevk commented May 13, 2024

What does margin refer to here? Criteria?

@emilio
Copy link
Contributor Author

emilio commented May 13, 2024

Distance with the viewport (as in, IntersectionObserver margins etc).

@annevk
Copy link
Member

annevk commented May 13, 2024

Thanks! This would be reasonable to standardize more. Some relevant WebKit code:

@khushalsagar
Copy link
Contributor

I'm wondering if content-visibility is a good concept to build on for this throttling; since the goal is similar: minimize rendering cost of content not relevant to the user (as opposed to just visible). For example, IIUC c-v will force layout for find-in-page. I'm wondering if lifecycle updates should similarly be resumed for offscreen iframes when the user triggers find-in-page, it's possible that a DOM update (which populates the content the user is searching for) is blocked on the next rAF.

@vmpstr might have input based on edge cases like this addressed for c-v.

@vmpstr
Copy link
Member

vmpstr commented May 13, 2024

For content-visibility, it's not a comprehensive list but selection, focus, and accessibility (find in page specifically) are all things that cause us to do rendering. FWIW, content-visibility: auto also has a user-agent defined margin for visibility that causes it to be relevant, which is similar to the iframe one if I understand correctly.

I don't think specifying the exact extent of this margin is worthwhile, but specifying more explicitly cases where we don't want throttling is useful.

@szager-chromium
Copy link

IIRC, render throttling already has a carve-out that allows find-in-page to work correctly. I could be wrong.

We should be mindful that throttling rendering for off-screen iframes also prevents badly-behaved iframes from sabotaging battery usage and performance of the embedding page. In some situations chromium will throttle setTimeout and setInterval timers to 1s, and I wouldn't want requestAnimationFrame to become an escape hatch that allows an iframe to run lots of code at high frequency.

@past past removed the agenda+ To be discussed at a triage meeting label May 15, 2024
@zcorpan
Copy link
Member

zcorpan commented May 16, 2024

Also see w3c/IntersectionObserver#508 (comment)

What WebKit does there seems better from a privacy POV since it avoids the Text Fragment side-channel using APIs affected by thottling.

@emilio
Copy link
Contributor Author

emilio commented Jul 4, 2024

This is still on my list fwiw. I want to make a change to Gecko here to make it more consistent and confirm such a thing is web compatible before proposing it more formally.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

8 participants
@past @zcorpan @emilio @annevk @vmpstr @szager-chromium @khushalsagar and others