[css-view-transitions-1] What is the snapshot containing block for iframes?

[khushalsagar]

The spec here says that if an element is too large for its entire image to be captured, implementations can clip the image as long as the contents in the snapshot containing block are captured.

But for definition of snapshot containing block is ambiguous for iframes: "all areas of the window that could potentially display page content". The impact it has on clipping of images aside, I think it should be the iframe's ICB. @bokand can explain this better.

But this means we need a better way to decide how to clip the image if the transition is happening in an iframe. The goal with the SCB recommendation was so we at least capture the onscreen content the user is seeing but the whole iframe could be offscreen. I'm thinking the following:

• If the iframe is completely offscreen, just skip the transition. Why animate instead of directly flipping to the new state.
• If its onscreen (fully or partially) use the SCB of the top level frame to decide what should be captured in the images.

[bokand]

But for definition of snapshot containing block is ambiguous for iframes: "all areas of the window that could potentially display page content". The impact it has on clipping of images aside, I think it should be the iframe's ICB

Agree, the Snapshot Containing Block for an iframe should be that frame's Initial Containing Block

I'm thinking the following:

• If the iframe is completely offscreen, just skip the transition. Why animate instead of directly flipping to the new state.
• If its onscreen (fully or partially) use the SCB of the top level frame to decide what should be captured in the images.

I'm not a fan of making the clipping depend on the iframe's position. Theoretically the owning document could be scrolling or animating the iframe's position so the exposed part could change during the transition. This information might also need to cross process boundaries so could be out of date. It feels rather complex for something that seems to me like an extreme edge case?

Why not just do the simple thing and apply the clip in the same way we do for non-root elements? i.e. take the above definition of the snapshot containing block for an iframe and also clip the root to it. It's true that the author might move the iframe so that an area beyond the clipping region is shown but this doesn't seem like something that'll happen in practice (and if there are use cases for it we can discuss it then?). Doing cross-process rect intersections seems like it'll be difficult to get right in implementation and even harder to make interoperable across browsers...

FWIW the bug where this came up, the reporter mentioned this wasn't a real use case but was found during a certification/stress test.

[khushalsagar]

Why not just do the simple thing and apply the clip in the same way we do for non-root elements? i.e. take the above definition of the snapshot containing block for an iframe and also clip the root to it.

We already clip the root to SCB, see here. This was based on the assumption that SCB is always a reasonable size. That's true for main frames but not iframes since there the SCB can be any bounds chosen by the parent frame.

[khushalsagar]

This information might also need to cross process boundaries so could be out of date. It feels rather complex for something that seems to me like an extreme edge case?

FWIW the info has to be available to cross-process iframes because of IntersectionObserver (which needs to know whether elements in an iframe are visible to the user). But its a fair point that it can be stale. For VT the latency in updating it will be visually noticeable to the user. If this all sounds too complex we can just say that implementations can skip the transition if SCB exceeds an implementation-defined maximum.

[khushalsagar]

Actually I forgot about #9543 which talks about what to do with iframes which are offscreen. So I'll keep this issue focused on defining an iframe's SCB and how to deal with the case where its very large.

Proposed resolution

• Snapshot Containing Block for an iframe should be that frame's Initial Containing Block
• If the SCB exceeds an implementation defined maximum, the UA can skip the transition

[bokand]

Proposed resolution

• Snapshot Containing Block for an iframe should be that frame's Initial Containing Block
• If the SCB exceeds an implementation defined maximum, the UA can skip the transition

This sgtm!

[css-meeting-bot]

The CSS Working Group just discussed [css-view-transitions-1] What is the snapshot containing block for iframes?, and agreed to the following:

• RESOLVED: Snapshot Containing Block for an iframe should be that frame's Initial Containing Block
• RESOLVED: If the SCB of an iframe exceeds an implementation defined maximum, the UA can skip the transition

The full IRC log of that discussion

<TabAtkins> khush: defining the snapshot used for the block in the transition
<TabAtkins> khush: defined with two things in mind
<TabAtkins> khush: one was, this whole pseudo-dom we're making, how is it positioned in the doc during layout
<TabAtkins> khush: two was, which dom do you capture
<TabAtkins> khush: on mobile viewports, you have some part of UI that can be retracted (url bar, root scrollers)
<TabAtkins> khush: we want it so that if going A->B, capture the largest chunk of window that can potentially display page content, even if interactive widgets are hidden
<TabAtkins> khush: this is very specific to the top-level frame, we didn't describe iframes well
<TabAtkins> khush: implicitly it ended up being the ICB of the iframe.
<TabAtkins> khush: iframes can be scrolled offscreen, so trying to define it as the on-screen viewport doesn't map well
<TabAtkins> khush: so one proposal is for iframes, say the snapshot containing block is the ICB
<TabAtkins> khush: but someone filed a bug where they had a massive iframe, and it causes an OOM for us
<TabAtkins> khush: so either we define a way to clip the iframe snapshot to be reasonable sized, or give an affordance to the UA to skip the transition
<TabAtkins> khush: it seems like an edge-case people won't generally hit
<khush> q?
<TabAtkins> khush: So second proposal is if snapshot containing block exceeds a UA-defined max size, we can skip the transition
<fremy> q+
<bramus> scribe+
<bramus> TabAtkins: (missed)
<bramus> khush: (missed2)
<TabAtkins> TabAtkins: We already allow UAs to implicitly do whatever they need for OOM conditions. Good to call them out if they might be common, but don't *need* an explicit allowance for it.
<bramus> s/(missed)//
<bramus> s/(missed2)//
<TabAtkins> khush: The question here is because there' two design choices. One is, when this came up for elements, if you have a massive element, the spec recommends capturing at least the on-screen portion fo the element
<TabAtkins> khush: For iframes - for OOPIFs it's hard to track where on the screen the iframe is
<TabAtkins> (out of process iframes)
<TabAtkins> khush: So the question was if we should try to figure out where the iframe is and capture the ons-creen part, or just say "you amde a massive iframe, sucks to be you"
<miriam> ack fremy
<khush> q?
<TabAtkins> fremy: I was wondering why we special-case iframes, but khush seems to have answered that
<TabAtkins> fremy: is it really a little difficult, or *impossible* to tell this? good for consistency if possible.
<TabAtkins> fremy: But also agree with TAb, if you'rea bout to crash the browser do whatever you need to avoid that.
<TabAtkins> fantasai: So I think the OOM condition doesn't *have* to be in the spec
<TabAtkins> s/fantasai/fremy/
<TabAtkins> fremy: so if you have a big document but a small iframe, are you snapshotting the hwole document or the part that's scrolled?
<TabAtkins> khush: a screenshot of the iframe bounds. for the embedded dcument that's what we'll define the containing block as
<TabAtkins> fremy: So this is only an issue if the <iframe> element is very big, not if the content of the iframe is big
<TabAtkins> khush: yes
<miriam> q?
<TabAtkins> khush: to answer how difficult, i think because of web features like intersectionObserver, we do send this info to the embedded document, but I haven't looked into the details yet
<TabAtkins> khush: I'd like to take the massive iframe resolution now, and we can revisit if necessary to do a more correct thing
<khush> res 1: Snapshot Containing Block for an iframe should be that frame's Initial Containing Block
<khush> res 2: If the SCB exceeds an implementation defined maximum, the UA can skip the transition
<TabAtkins> miriam: So any objections to first resolution?
<TabAtkins> RESOLVED: Snapshot Containing Block for an iframe should be that frame's Initial Containing Block
<TabAtkins> astearns: question - just for iframes?
<TabAtkins> khush: yes
<TabAtkins> astearns: then second resolution should specify that
<TabAtkins> RESOLVED: If the SCB of an iframe exceeds an implementation defined maximum, the UA can skip the transition
<TabAtkins> fantasai: Did we need a similar resolution for the main window?
<TabAtkins> astearns: For main if already scopes to the visible rect