Call the view-transition page-visibility change steps

[noamr]

This allows the CSS view-transitions spec to react to page visibility changes. Specifically, skip the active transition once a page is hidden.

See w3c/csswg-drafts#9543
and CSSWG resolution: w3c/csswg-drafts#9543 (comment)

• At least two implementers are interested (and none opposed):
  • Chromium (implemented)
  • WebKIt (View Transitions API Level 1 WebKit/standards-positions#48) this is part of L1
  • Gecko (View Transitions API mozilla/standards-positions#677) this is part of View Transitions L1
• Tests are written and can be reviewed and commented upon at:
  • https://wpt.fyi/results/css/css-view-transitions/transition-in-hidden-page.html
• Implementation bugs are filed:
  • Chromium: already implemented
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1823896
  • WebKit: https://bugs.webkit.org/show_bug.cgi?id=271248
• MDN issue is filed: CSS View transitions: Add a note that view transitions are immediately skipped when page is hidden mdn/content#32748
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

/infrastructure.html ( diff )
/interaction.html ( diff )

[domenic]

Spec text looks good with a nit. Since this is a tricky area, I have some test questions.

Can you confirm:

• It's tested that document's visibility state is updated before running the view transition page visibility change steps?

• It's tested that view transition page visibility change steps come before firing visibilitychange?

• Screen orientation change steps coming before view transition page-visibility steps is intentional, and implemented in Chromium? (Bonus points if you can test it, but I suspect it's not testable. Although https://github.com/web-platform-tests/wpt/blob/c399cf9e2773f36947383a12d90635562533a93c/screen-orientation/onchange-event.html#L20-L44 seems like maybe it's changing the orientation??)

[noamr]

Spec text looks good with a nit. Since this is a tricky area, I have some test questions.

Can you confirm:

• It's tested that document's visibility state is updated before running the view transition page visibility change steps?

Yes! see https://github.com/web-platform-tests/wpt/blob/master/css/css-view-transitions/transition-in-hidden-page.html#L22

• It's tested that view transition page visibility change steps come before firing visibilitychange?

Oops, testing the opposite :(
Corrected in web-platform-tests/wpt#45342

• Screen orientation change steps coming before view transition page-visibility steps is intentional, and implemented in Chromium? (Bonus points if you can test it, but I suspect it's not testable. Although https://github.com/web-platform-tests/wpt/blob/c399cf9e2773f36947383a12d90635562533a93c/screen-orientation/onchange-event.html#L20-L44 seems like maybe it's changing the orientation??)

The order here doesn't matter and is not observable, as the screen orientation steps only apply when the document is visible and the view transition steps only apply when the document is hidden.

[noamr]

I've received feedback internally that perhaps we should move this to after firing visibilitychange, as the observable behavior is promise-based. That's what the current implementation+WPTs do. Any objection @domenic ?

[domenic]

Can you expand on the reasoning? It seems we have a medium-strong precedent that visibilitychange is last, so I'd like more explanation before we start breaking that, including reasoning on what types of features should go before vs. after so that we can know in the future where to put things. What kind of code are developers writing, and what is the impact on that code with before vs. after? Why is this case different than screen orientation, device posture, or Web NFC?

[noamr]

Can you expand on the reasoning? It seems we have a medium-strong precedent that visibilitychange is last, so I'd like more explanation before we start breaking that, including reasoning on what types of features should go before vs. after so that we can know in the future where to put things. What kind of code are developers writing, and what is the impact on that code with before vs. after? Why is this case different than screen orientation, device posture, or Web NFC?

For screen orientation and device posture, the visibility change steps queue a task to fire a different event. For WebNFC, some promises might be rejected which would be similar to this, but I'm not certain the order of operations is tested.

So in essence, the consistent way of going about it would be to skip the transition after firing the event, or running them before but internally queuing a task to resolve the promises. Perhaps the latter is cleaner, but in terms of order of operations it's the same.

[domenic]

Sorry ,that isn't enough detail for me. Can you help with

What kind of code are developers writing, and what is the impact on that code with before vs. after?

[noamr]

Sorry ,that isn't enough detail for me. Can you help with

What kind of code are developers writing, and what is the impact on that code with before vs. after?

Imagine this code:

const transition = document.startViewTransition();
onvisibilitychange = () => {
  if (document.hidden) { 
    cleanupVisualStuffWhenHidden();
  }
};

transition.finished.then(() => {
  cleanupTransitionSpecificStuff();
});

/* After these are called, the user switches tabs or minimizes the window */

With the current spec PR, cleanupTransitionSpecificStuff() will happen before cleanupVisualStuffWhenHidden().
If we swap the order, or queue a task to skip the transition, cleanupVisualStuffWhenHidden() will be called before cleanupTransitionSpecificStuff().

[domenic]

Thanks for explaining. Let's queue a task, then, as that gives implementations the most scheduling flexibility and is most consistent with what comes before.

[noamr]

Thanks for explaining. Let's queue a task, then, as that gives implementations the most scheduling flexibility and is most consistent with what comes before.

Done. (w3c/csswg-drafts#10168)