[css-view-transitions-1] Handle startVT/cross-doc transitions when Document is hidden

[khushalsagar]

If startViewTransition is called while a Document is hidden. Or the document is hidden at any point during the transition's lifecycle, we don't do anything special. We should probably explicitly skip the transition if the Document is hidden.

Not sure what to do with iframes. The UA can stop rendering opportunities if the iframe is far enough for the viewport. Should we assume its hidden?

The spec way of when a Document is hidden can be based on this : The step labeled Rendering opportunities prevents the user agent from updating the rendering when it is unable to present new content to the user. If the Document is in this state, skip all ViewTransitions?

[noamr]

What would happen given the current spec is that the transition would be delayed until the page is visible or the timeout passes. Perhaps for iframe this is OK, and for explicitly hidden pages we can skip immediately?

[khushalsagar]

What would happen given the current spec is that the transition would be delayed until the page is visible or the timeout passes.

Right now it depends on when the page is hidden. If its before rendering has been frozen then we'll keep waiting for the next frame. If its during rendering frozen then we timeout. And if its after the DOM has been constructed then it will wait until all animations are finished. I'm not sure how we deal with animation progress for hidden Documents but if that's checked when the Document is made visible again then likely we'll discover the transition to be finished then?

Perhaps for iframe this is OK, and for explicitly hidden pages we can skip immediately?

Sounds reasonable. If the Document is hidden, that probably means the user doesn't care to see an animation when its made visible again. We can render the new DOM directly.

For the iframe case, browsers can stop rendering the iframe if its far off from the viewport. That means sometimes authors might see a timeout error if the iframe goes offscreen right after the transition was initiated. Its rare enough that we can ignore this case. But this was why I was leaning towards using a "rendering opportunity" based definition. So we skip for any case where the Document is not going to produce any more frames.

[khushalsagar]

Proposed Resolution
Any active transition is immediately skipped when the Document's visibility state changes to "hidden". If startVT is called while the Document is in this state, that is also immediately skipped.

It's unclear what to do for offscreen iframes, filed #9839 for that.

[khushalsagar]

The proposal is for same and cross-document transitions.

[css-meeting-bot]

The CSS Working Group just discussed [css-view-transitions-1] Handle startVT/cross-doc transitions when Document is hidden, and agreed to the following:

• RESOLVED: Skip transitions if the document state is hidden (or changes to hidden)

The full IRC log of that discussion

<TabAtkins> khush: this is about what to do if, in any phase of he transition, the doc is hidden (you switch tabs)
<TabAtkins> khush: two quirky cases
<TabAtkins> khush: one, tab is hidden before you even cache the old dom's appearance
<TabAtkins> khush: In the spec we wait for a frame to happen so we can cache, and eventually time out
<TabAtkins> khush: confusing to authors
<TabAtkins> khush: second is we cache the screenshot, create the pseudo, but animations don't tick
<TabAtkins> khush: in principle they tick, like a web animation, but unless we queue a task for when the transition *should* finish we just hang onto the memory for the snapshot indefinitely
<TabAtkins> khush: both are bad. there's no reason to keep the machinery alive when the doc isn't visible. user should just see the new state when they arrive
<TabAtkins> khush: so proposal is, if the doc ever changes to hidden, just flip to the end state
<TabAtkins> khush: quiriker case is iframes. if you scroll it off-screen enough, browsers will throttle rendering
<emilio> q+
<TabAtkins> khush: so maybe another resolution - if an iframe isn't going to get rendering opportunities, just skip the transition. if needed i can go into detail about where that change will happen in html
<bramus> q+
<TabAtkins> khush: So first proposed resolution: if page is hidden, skip transitions.
<miriam> ack emilio
<TabAtkins> emilio: seems reasonable. what's the author-visible behavior? does promise reject or something else?
<noamr> q+
<flackr> q+
<TabAtkins> khush: there's already a bit in the API where a transition can skip to the end at any point.
<TabAtkins> khush: So all the promises define how they act in this case already
<TabAtkins> khush: [describes the promises behavior]
<TabAtkins> emilio: so that won't cause spurious exceptions... unless you await the ready promise?
<TabAtkins> emilio: Might be bad to test
<TabAtkins> TabAtkins: we dont' *reject* the promises, do we?
<TabAtkins> khush: we do reject the XXX promise because it indicates there is no pseudo-elements generated
<noamr> We reject the ready promise
<TabAtkins> khush: I'd expect most authors to have written error-handling code
<TabAtkins> emilio: ehhhhhhh
<TabAtkins> khush: if you do try to do something to the pseudo-element, your code will be wrong anyway and throw other errors
<TabAtkins> emilio: yeah my concern is just that it's really easy to write code that doesn't test for this
<TabAtkins> vmpstr: ready promise already rejects on timeout
<TabAtkins> emilio: ready promise is okay, i just don't want the other promises to reject
<miriam> ack bramus
<TabAtkins> bramus: Maybe we should only do that if animations are linked to document timeline?
<TabAtkins> khush: spec already says the only transition that holds the pseudo dom are those attached to document timeline
<TabAtkins> khush: So if the browser is slow internally or your callback is slow, that can already cause a timeout and reject the ready promise
<TabAtkins> khush: This also applies to cross-document transitions
<miriam> ack noamr
<TabAtkins> noamr: I think we already have spec language that says we can skip transitions for UA-defined reasons, that might be a good place to put the "if iframe is hidden" part since that's also UA-defined
<TabAtkins> noamr: And I suggest that if whole document is hidden (document.hidden) we should never expect a VT to work
<khush> q?
<TabAtkins> flackr: I didn't fully catch the reponse to Bramus' question, i think i have same concern
<noamr> q+
<TabAtkins> flackr: could create unpredictable behavior for transitions that last a long time or have a non-monotonic timeline
<miriam> ack flackr
<TabAtkins> bramus: it was covered
<TabAtkins> khush: If the only animations you ahve are non-document timeline'd, we already don't let you hold a transition forever
<noamr> q-
<TabAtkins> khush: when we walk thru the transitions and ask if there's anything that should keep the pseudo-dom alive, we ignore any that aren't attached to the document timeline
<TabAtkins> flackr: So you're not allowed to do this today
<TabAtkins> khush: Yeah, you'd have to manually hack it up
<TabAtkins> khush: There's an issue about us allowing raf/script-driven animations, and have an option to let people say "please dont' auto-shut-off my animation, I know what i'm doing"
<miriam> ack fantasai
<TabAtkins> fantasai: I hear emilio's concern about testing pathways
<TabAtkins> fantasai: but if we already have that problem, making it happen more often is helpful because it's more likely to occur in front of the dev
<TabAtkins> fantasai: re: what the user expects, since transitions should be temporary, it seems okay to just skip
<khush> q?
<vmpstr> q+
<TabAtkins> fantasai: so it seems that making them skip on hidden seems reasonable, and hopefully helps devs hit the error case more often if their code is broken
<miriam> ack vmpstr
<TabAtkins> vmpstr: the only thing from Bramus' point, there *are* cases where you want to control the animation with WebAnimations, so you can animation-play-state:paused and then respond to user input
<TabAtkins> vmpstr: Skipping on *those* cases if you swtich the tab seems unfortunate
<noamr> q+
<TabAtkins> khush: It's a behavior change you'd have to explicitly code for now
<TabAtkins> bramus: Isn't that already covered by the conditions?
<TabAtkins> khush: spec says keep the structure alive if the animation is running or paused
<TabAtkins> bramus: So should we remove the paused condition?
<TabAtkins> khush: I think I'm concurring with elika, since there are situations where this can occur already (gpu busy, your callback is longer than expected), in some cases the promise will reject already
<TabAtkins> khush: And in these scenarios the most logical thing to do is skip the transition
<miriam> ack noamr
<TabAtkins> noamr: The whole thing about paused transitions - at this time the document isn't interactive
<TabAtkins> noamr: It's a strange state, needs to be dealt with holistically
<TabAtkins> khush: proposed resolution: Skip transitions if the document state is hidden (or changes to hidden)
<TabAtkins> miriam: objections?
<TabAtkins> bramus: And this is with the current conditions in the spec right now?
<TabAtkins> khush: yes
<TabAtkins> RESOLVED: Skip transitions if the document state is hidden (or changes to hidden)