WebKit export of https://bugs.webkit.org/show_bug.cgi?id=265734

[mattwoodrow]

WebKit export from bug: [view-transitions] Exclude fragmented boxes from capture

[wpt-pr-bot]

This patch has been exported from WebKit; it will be approved automatically once the downstream patch is r+.

[wpt-pr-bot]

The review process for this patch is being conducted in the WebKit project.

[gsnedders]

@nt1m @mattwoodrow do we think this can land as is, or can something be done to mitigate the Firefox flakiness? (cc @emilio)

[emilio]

It seems the test is mostly fuzzy, not broken? Maybe using animation-play-state: paused rather than animation-duration: 500ms helps mitigate it

[emilio]

(On the other hand it's visibility: hidden, so shouldn't matter I think? I can look at it more tomorrow, feel free to land as-is)

[mattwoodrow]

Is there any way to view to failing images?

The idea of the test is that the 'target' view transition name animation is running, but the new/old images should be identical, so shouldn't be racy.

The 'root' animation is hidden, so anything not in target (including target itself if the spanning got detected as being fragmented) isn't in the capture at all.

The failing fuzz values seem fairly large, is it possible that one of the new/old captures is missing, so it's racily capturing a fade-in/out?

[emilio]

@mattwoodrow so running the test on firefox nighly, I see that what happens is that we capture the old state just fine because it's not fragmented yet, and then fade it out, and skip the new one because it's fragmented, so there's a fade-out animation of the old content that is what's causing the flakyness.

I think (from memory, haven't dug, lmk if I'm wrong) that's right per spec? If so I think you need to hide the ::view-transition-old(target) pseudo to make the test not have that animation.