search

web-platform-tests / wpt

Test suites for Web platform specs — including WHATWG, W3C, and others
https://web-platform-tests.org/
Other
4.89k stars 3.05k forks source link

[css-view-transitions-2] navigation/hide-before-reveal.html appears to expect the inbound VT to be cancelled before pagereveal. #47828

Closed mattwoodrow closed 3 days ago

mattwoodrow commented 2 weeks ago

If I'm reading this test correctly, it: does a navigation, then in the new page establishes render blocking, minimizes the window while render blocked, removes render blocking, restores the window. The test is expecting that the VT gets skipped.

The spec says the inbound view transition isn't created (and set as the active view transition for the Document) until the page is revealed, which happens after the window is restored (that's the first time the visibility state is visible, and no render blocking is in place).

The https://drafts.csswg.org/css-view-transitions/#page-visibility-change-steps cancellation that would happen when the window is minimised don't have any effect, since it happens before page reveal.

noamr commented 2 weeks ago

Thanks, this is actually a missing spec bit. VT-2 needs to augment the page visibility change steps to also nullify inbound view-transition params.

mattwoodrow commented 2 weeks ago

Ah right, that makes sense!

I can implement that in WebKit soon.

Speaking of, is the 'queue a global task' part of the visibility change steps correct?

It seems like we can have the following order of events:

visibility-change to hidden, task queued visibility-change to visible startViewTransition run visibility change task, fail 'active view transition is null' assert.

I see that exact sequence in window-resize-aborts-transition-before-ready.html if I add the task, and also a failure in the second subtests of transition-in-hidden-page.html (since the rejection happens later than the test is expecting).

noamr commented 1 week ago

See https://github.com/w3c/csswg-drafts/pull/10815