1979005 - View transition elements that contain position:fixed descendants are not captured

Status: NEW

(Core :: Layout, defect, P3)

Description

[Swarup Ukil [:sukil]]

Attachment: pos-fixed-VT.png

This bug is for:

• named-element-with-fix-pos-child-new.html
• named-element-with-fix-pos-child-old.html
• new-content-escapes-clip-with-abspos-child.html
• old-content-escapes-clip-with-abspos-child.html

Off the edited test configuration (and attached image!) of the named-element-with-fix-pos-child-new.html test case listed above, the failure seems to be an issue of image capturing. From the image we see:

1. On nightly, the green fixed box is clipped to the blue "target" box size, while we expect the green box to bleed over the blue "target" box.
2. On nightly, we see a red box in bottom right corner, however we should instead see the grey "child" box from the original test case --- this is because the grey box should be rendered over the red box in this config.

1 & 2 together imply (to me) that positioning is well handled, but our current implementation expects our "target" element's capture/snapshot to include position:fixed descendants too, however for some reason or another it isn't. Note: had we artificially made our "target" have larger width and height like 300x300 we would see both the green and grey boxes be rendered correctly.

Comment 1

[Swarup Ukil [:sukil]]

Attachment: test-pos-fixed-VT.html

Comment 2

[Emilio Cobos Álvarez [:emilio]]

To fix this it seems like we should add the abspos / fixed pos area to the ink overflow rect. But that is a somewhat scary change...

Comment 3

[Marco Mucci [:MarcoM]]

Added 'needinfo' for Emilio to follow up on.

Comment 4

[Emilio Cobos Álvarez [:emilio]]

Daniel do you happen to have context on why abspos elements are not part of the ink overflow rect of their in-flow ancestors? Conceptually it may make sense to do so (though it's a rather scary change).

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #4)

Daniel do you happen to have context on why abspos elements are not part of the ink overflow rect of their in-flow ancestors?

(I assume it contributes to their abspos-cb-ancestor's ink-overflow instead, right?

I don't specifically recall the reasoning, but here are some reasons that come to mind:

(1) by analogy/similarity to scrollable overflow (abspos elements escape in-flow scroller ancestors, so they trivially don't want to contribute to their in-flow parents' scrollable overflow; and perhaps things are easier to maintain if we treat ink overflow the same way)

(2) contributing to their parents' ink-overflow-rect would result in pretty-massive overflow-area sizing in many cases; e.g. if you have some nested column of in-flow divs, with an abspos footer and header inside the innermost one, then that whole column of divs would end up with the whole viewport as its ink-overflow-rect.

(3) if you perform some mutation that requires a repaint but doesn't require a reflow (e.g. adjusting top on a position:relative element), then its whole in-flow tree needs a repaint because it's been moved, but its fixed-pos descendants typically don't need a repaint (unless they're statically-positioned, but I imagine we handle that separately). So we don't need to invalidate the area of those fixed-pos elements for this sort of a change; and so in general, the out-of-flow descendants whose OOF-CB is further up the tree don't need to contribute to their in-flow ancestors' ink overflow.

So I think those are reasons it's convenient/efficient to avoid contributing to the in-flow-parent's ink-overflow. I don't imagine there's any sort of correctness reason to avoid it; there's just potentially a performance cost to doing it (though perhaps that's more relevant in the pre-WebRender days).