View Transition finished promise timing change

concepts

1. finished Promise Timing

   ViewTransition.finished now resolves after the animations commit to the next paint, not at the keyframe end. Removes a tricky one-frame race.

2. No-flicker Cleanup

   The flicker motivation: run a transition with style fixup in .finished.then(), with an optional 16ms fake-work injection to widen the gap.

3. Timing Diagram

   Side-by-side waterfall of the pre-140 vs post-140 lifecycle showing exactly where the cleanup script slots in relative to the frame commit.

4. Cleanup Race

   Live transition with a chained .finished.then() handler that logs perf timestamps so you can see the cleanup paint cleanly in 140.

5. Transition Sequencer

   Chains three view transitions using .finished: A → B → C, each awaiting the previous before starting. Before Chrome 140, finished resolved too early, causing flicker overlap. A timeline visualization marks each transition start/end and the finished event. "Old timing" toggle simulates the pre-140 immediate-resolve bug.

why it shipped

The current finished promise timing happens within the rendering lifecycle steps. This means that code that runs as a result of promise resolution happens after the visual frame that removes the view transition has been produced. This can cause a flicker at the end of the animation if script moves some styles around in an attempt to preserve visually similar

references

• ChromeStatus entry