How do we perform the navigation at the end of a preemptive transition

[bokand]

When the gesture ends and a navigation is about to occur we need to decide exactly how that swap happens:

1) Do we simply paint hold and assume the end state of the gesture will roughly match the incoming state 2) Do we perform a plain root-only cross-document view transition to cross fade from the end state screenshot to the live incoming page? 3) Do we allow the incoming page to define a transition from the end state to the live page?

Option 1 seems most straightforward and might be a good initial behavior - in the typical case this should look ok.

Options 2 and 3 seem to add a fair amount of, at least conceptual, complexity since we're now coordinating 2 view transitions to navigate to the incoming doc (1 when the gesture is active and 2 when actually navigating between documents). However:

Option 2 would improve this to make the transition a bit less harsh, especially in cases where the restored page changed significantly (e.g. starts loaded at the top rather than the historical scroll offset).

Option 3 seems rather complex but I think would be required to enable fully native like transitions. Consider the GMail example from the explainer:

Fully performing the gesture only shrinks the current view subtly. It's only on release that the current view snapshot is shrunken back into the previous page. Maybe the author could setup some kind of chained animation such that when the gesture finishes we play a "closing" animation. But the back action is triggered as soon as the gesture is completed (and may be out of the browser's hands - we could delay invoking history back but that seems bad).

We could reuse the outgoing page's snapshot state so that the incoming page can setup its transition to animate smoothly from the outgoing page's end state. In this case, shrink the outgoing snapshot into the inbox view.

[khushalsagar]

Maybe the author could setup some kind of chained animation such that when the gesture finishes we play a "closing" animation.

This seems like the simplest option. ViewTransition already blocks on animations on all pseudo-elements finishing. So we could do something like the following:

1. At touch up, finish the timeline to 100%.
2. Dispatch an event notifying that the gesture has been invoked. The author can use this to add document timeline based animations to the pseudo-elements.
3. Wait for the ViewTransition to finish. It will by design wait for the animations added in step 2 to complete.

Then we can go with option 2? Except the cross-fade is an internal detail (not a ViewTransition exposed to the author).

[khushalsagar]

The navigation delay here is a good consideration. Delaying the navigation commit on a time based animation on the old Document means all the post commit network fetches, parsing and script execution is also delayed.

Running the "closing animation" on the new Document could instead allow us to parallelize loading of the new Document with this animation. The animation could in fact allow papering over the latency of the navigation in a way.

I'm just unsure of how to seamlessly stitch the animation together between the Documents. Because we have 2 versions of the new Document, the UA screenshot and the live Document. All the other view-transition pseudo-elements would also have the complete Node state. It's also the same as VT trying to cache a visual representation of the DOM, now we need to cache a visual representation of the pseudo-DOM generated by VT...

---

Given the complexity with the above, let's look at the data? For a non-BFCache navigation, what is the network delay before the navigation is ready to commit. If the "closing" animation is reasonably short, then it would hopefully be parallelized with the time to commit.

[bokand]

If the "closing" animation is reasonably short, then it would hopefully be parallelized with the time to commit.

I think the "closing" animation is associated with being on the new page in the user's mind though. I think it'd be a desirable UX pattern for the animation to "pause" until the navigation commits, then play to completion when we're ready to swap to the new document / already on the new document.

i.e. With the gmail example above - if the network takes a really long time, as a user, I'd make more sense to me if the animation stopped at the old page slightly shrunken state (perhaps pulsing to indicate work/waiting) - then shrink into the inbox when the old page is ready. Put another way, it'd be surprising if the old page shrunk into the inbox but the page remained non-interactive because we're still waiting on network.