[css-view-transitions-2] Starting a same-doc view transition while a cross-doc view transition is pending

[noamr]

The current behavior in the spec is that starting any view transition cancels the active one, which means that the following edge cases might have unexpected results:

• A capture is initiated for a document navigation and script initiates a transition before the document unloads. should we ignore document.startViewTransition() calls during a navigation initiated transition?

• On the new Document, script initiates transition before the navigation initiated transition could finish (before pagereveal). Given that the navigation initiated transition will be before the first frame of the new Document was rendered, should we ignore it and let the MPA transition go through?

@khushalsagar @bokand @vmpstr

[vmpstr]

I agree with both the points. In general I think MPA transition should take "priority" over SPA. Another case is when an SPA transition is already happening while the user initiates an MPA navigation with a transition.

In all of these, we should ensure that the MPA transition runs. In the future, with scoped transitions, we might be able to allow both to run in some cases, but if it's not possible MPA should win.

[noamr]

I think that there are good reasons keep the current behavior. e.g. if the author prefers to run an entry animation instead of the MPA transition, go ahead. "last transition wins" is easy to reason about and consistent, while "MPA wins and last transition wins at a lower priority" is more complicated with questionable value.

[khushalsagar]

A same-document transition being started before the new Document has produced a single frame and we have an MPA transition seems like a bug? If the developer legit wants an entry SPA transition they can abort the MPA transition in reveal and then initiate an SPA transition.

I'd be fine with either, whatever would help authors more here.

[noamr]

A same-document transition being started before the new Document has produced a single frame and we have an MPA transition seems like a bug? If the developer legit wants an entry SPA transition they can abort the MPA transition in reveal and then initiate an SPA transition.

Is this different/more buggy than starting an SPA transition and then starting a new one before we even got the callback?

[noamr]

Looking at the current spec, either way works for me. We can say that the MPA transition only becomes the "active view transition" on page reveal, which means that on page reveal it would skip any existing SPA view transitions (causing their update callback to be fired). In the current spec MPA transition sets the active view transition early, which would mean it would be skipped by an early startViewTransition.

[noamr]

This is actually a duplicate of #8678, merging that one into this one.

[khushalsagar]

We should keep the MPA transition until we've had at least 1 frame drawn? Otherwise I can't see any reasonable use-case where the author would want to overwrite the MPA transition before that. Doing so will result in an abrupt swap between the 2 Documents.

Once the new Document has drawn 1 frame, it's possible a network update changes its content drastically or the user interacts with the page.

Maybe reveal is a reasonable hook for that. Its fired right before we'll draw the first frame. After that point, there can be events where skipping the current transition is the right thing to do.

[flackr]

Given that there will be frameworks that sometimes navigate as an SPA and sometimes navigate as an MPA, I think we should be consistent and have the last transition win. In this case, the SPA would cancel the MPA transition, unless / until we work out the details on how to combine transitions.

Starting an SPA before first frame has been rendered is perfectly fine from a spec POV since the API will ensure the current state is rendered before calling the callback to produce the destination state.

[noamr]

Summarizing the internal group discussion, the direction is to propose resolving on the current wording of the spec, which means that a startViewTransition call that starts at any time after the cross-document view-transition has started (either in the old or new doC) would skip the cross-document view-transition. This would make cross-document transitions consistent with same-document transitions in this case.

[vmpstr]

Does this include startViewTransition calls on the outgoing page that happen after the MPA version has triggered?

[noamr]

Does this include startViewTransition calls on the outgoing page that happen after the MPA version has triggered?

For consistency, yes. It means that calling startViewTransition during the capture-frame or pagehide would skip the MPA transition

[khushalsagar]

It means that calling startViewTransition during the capture-frame or pagehide would skip the MPA transition

Is that the case based on the spec text here. Looks like we clear the outbound VT before pageHide is dispatched? But yeah any script which happens to run before the rendering opportunity which is cached will skip it and that's fine.

[khushalsagar]

Filed #9543 to discuss transition requests when the Document is hidden. I think the pageHide case will fall in this category?

[noamr]

Filed #9543 to discuss transition requests when the Document is hidden. I think the pageHide case will fall in this category?

No, pagehide is only for page unloading or going into BFCache. visibilitychange is about hidden documents.

[khushalsagar]

Do we not mark the Document hidden before dispatching pageHide?

[noamr]

Do we not mark the Document hidden before dispatching pageHide?

Yes, we do. sorry, my misunderstanding about #9543.

[khushalsagar]

Proposed Resolution: startViewTransition overwrites an existing cross-document ViewTransition (in the old or new document).

[css-meeting-bot]

The CSS Working Group just discussed [css-view-transitions-2] Starting a same-doc view transition while a cross-doc view transition is pending, and agreed to the following:

• RESOLVED: A startVT() called on the new page will force-finish an MPA VT even if a frame hasn't painted yet. (startVT() late in the old page is still undefined)
• RESOLVED: startVT() on the old doc is ignored if there's an active MPA VT running, but its callbacks are still dispatched

The full IRC log of that discussion

<TabAtkins> khush: We can only have one VT at a time
<Rossen_> ч?
<Rossen_> q
<TabAtkins> khush: So what to do if the page starts a same-doc VT (script calls .startViewTransition) while a cross-doc is running?
<TabAtkins> khush: In same-doc we take latest; if you start a new one it force-finishes the old one
<TabAtkins> khush: Proposal is to do the same
<TabAtkins> khush: Some debate. If you were navigating and just arrived on the page, do you actually want an abrupt transition and then start the new one?
<flackr> q+
<TabAtkins> khush: In the extreme the doc hasn't drawn a frame yet
<TabAtkins> khush: So our proposal is we delay setting up a VT object on the doc until the page has drawn one frame
<TabAtkins> khush: After that, if you call the JS API, the behavior is the same as same-doc transitions, latest wins
<Rossen_> ack flackr
<TabAtkins> flackr: I can think of lots of cases where devs use a transition for an intro animation to the page
<TabAtkins> flackr: It's common to start a transition before the element is drawn, that's why we delay a frame
<TabAtkins> flackr: So your proposal is that even if youc all startViewTransition before the first frame, it cancels the MPA?
<TabAtkins> khush: No the other way. Conceptually the cross-doc transition isnt' set up until a specific point in the doc lifecycle when a frame has painted.
<TabAtkins> khush: Before that, there is no cross-doc view transition.
<TabAtkins> flackr: So in an MPA you've started the setup on the old page. For consistency with frameworks that can do both SPA and MPA, I'd strongly prefer the MPA transition be canceled if you start a SPA VT even before the old page has painted
<TabAtkins> khush: Use-case?
<TabAtkins> flackr: There are frameworks that'll sometimes SPA or MPA depending on various things. Would be hard to work with it only sometimes canceling
<TabAtkins> khush: My problem is, if you do it before the page has drawn a frame, then by design you'll ahve an abrupt transition.
<TabAtkins> flackr: Yeah but that's the same as if you call startVT() before the previous VT was able to do anything useful
<TabAtkins> khush: It's about timing. If we defer it, then anything you do before the page reveal contributes to the state of the DOM
<TabAtkins> (I'm a little lost fwiw.)
<Rossen_> ack fantasai
<TabAtkins> fantasai: Just to confirm we're talking about calling startVT() on the new page, not on the old page?
<TabAtkins> khush: Yes. There's a separate question about what to do with a VT on the old page, but it's very unlikely anyway
<TabAtkins> flackr: I do just think it's still consistent with the SPA form - we *have* already started the cross-doc VT by the time the new page loads.
<TabAtkins> khush: This isn't a hill I want to die on, I can take either resolution. Authors can just not call it if the behavior is wrong.
<TabAtkins> khush: My proposal was just to hopefully get a "right behavior" by default if you didn't think about it well
<TabAtkins> flackr: And my preference is to get a consistent answer between MPA and SPA.
<TabAtkins> flackr: So my proposal is startVT() force-finishes the MPA transition even if it hasnt' captured the first frame yet
<fantasai> TabAtkins: overlapping VTs seems a mistake
<fantasai> TabAtkins: so prefer to do the predictable thing than trying to make it "smart"
<TabAtkins> fantasai: make it clear - startVT() on the *new* page that cancels the MPA transition
<TabAtkins> TabAtkins: Just making it clear - startVT() late in the old page is currently undefined then, right? And we'll figure it out later.
<TabAtkins> khush: Yes. Let's resolve on the new-page startVT() now.
<khush> q+
<Rossen_> ack khush
<TabAtkins> RESOLVED: A startVT() called on the new page will force-finish an MPA VT even if a frame hasn't painted yet. (startVT() late in the old page is still undefined)
<TabAtkins> khush: Could we decide on the old page behavior? Seemed to be consensus on "dont' cancel" - you're leaving the page and capturing the last frame, doesn't make sense to cancel the MPA
<TabAtkins> khush: so proposed: startVT() is ignored on the old doc if there is an active MPA VT
<TabAtkins> flackr: I think you still need to run update, tho.
<TabAtkins> Rossen_: Sounds like there isn't consensus quite yet, then.
<TabAtkins> khush: I'm happy with the resolution, we can bring it up if we find issues.
<TabAtkins> RESOLVED: startVT() on the old doc is ignored if there's an active MPA VT running, but its callbacks are still dispatched