Add the suffix to cancelled view transition names #35485
Merged
+5
−1
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
sebmarkbage
force-pushed
the
fixcancelvt
branch
from
29a3ede to
b551a86
Compare
github-actions
bot
added
the
React Core Team
|
Comparing: 5aec1b2...b551a86 Critical size changesIncludes critical production bundles, as well as any change greater than 2%:
Significant size changesIncludes any change greater than 0.2%: (No significant changes) |
jackpope
approved these changes
Jan 14, 2026
github-actions bot
pushed a commit
that referenced
this pull request
Jan 14, 2026
When a View Transition might not need to update we add it to a queue. If the parent are able to be reverted, we then cancel the already started view transitions. We do this by adding an animation that hides the "old" state and remove the view transition name from the old state. There was a bug where if you have more than one child in a `<ViewTransition>` we didn't add the right suffix to the name we added in the queue so it wasn't adding an animation that hides the old state. The effect was that it playing an exit animation instead of being cancelled. DiffTrain build for [4a3d993](4a3d993)
github-actions bot
pushed a commit
to rickhanlonii/react
that referenced
this pull request
Jan 14, 2026
When a View Transition might not need to update we add it to a queue. If the parent are able to be reverted, we then cancel the already started view transitions. We do this by adding an animation that hides the "old" state and remove the view transition name from the old state. There was a bug where if you have more than one child in a `<ViewTransition>` we didn't add the right suffix to the name we added in the queue so it wasn't adding an animation that hides the old state. The effect was that it playing an exit animation instead of being cancelled. DiffTrain build for [4a3d993](facebook@4a3d993)
github-actions bot
pushed a commit
to rickhanlonii/react
that referenced
this pull request
Jan 14, 2026
When a View Transition might not need to update we add it to a queue. If the parent are able to be reverted, we then cancel the already started view transitions. We do this by adding an animation that hides the "old" state and remove the view transition name from the old state. There was a bug where if you have more than one child in a `<ViewTransition>` we didn't add the right suffix to the name we added in the queue so it wasn't adding an animation that hides the old state. The effect was that it playing an exit animation instead of being cancelled. DiffTrain build for [4a3d993](facebook@4a3d993)
sebmarkbage
added a commit
that referenced
this pull request
Jan 16, 2026
…35486) Stacked on #35485. Before this PR, the `startGestureTransition` API would itself never commit its state. After the gesture releases it stops the animation in the next commit which just leaves the DOM tree in the original state. If there's an actual state change from the Action then that's committed as the new DOM tree. To avoid animating from the original state to the new state again, this is DOM without an animation. However, this means that you can't have the actual action committing be in a slightly different state and animate between the final gesture state and into the new action. Instead, we now actually keep the render tree around and commit it in the end. Basically we assume that if the Timeline was closer to the end then visually you're already there and we can commit into that state. Most of the time this will be at the actual end state when you release but if you have something else cancelling the gesture (e.g. `touchcancel`) it can still commit this state even though your gesture recognizer might not consider this an Action. I think this is ok and keeps it simple. When the gesture lane commits, it'll leave a Transition behind as work from the revert lanes on the Optimistic updates. This means that if you don't do anything in the Action this will cause another commit right after which reverts. This revert can animate the snap back. There's a few fixes needed in follow up PRs: - Fixed in #35487. ~To support unentangled Transitions we need to explicitly entangle the revert lane with the Action to avoid committing a revert followed by a forward instead of committing the forward entangled with the revert. This just works now since everything is entangled but won't work with #35392.~ - Fixed in #35510. ~This currently rerenders the gesture lane once before committing if it was already completed but blocked. We should be able to commit the already completed tree as is.~
github-actions bot
pushed a commit
that referenced
this pull request
Jan 16, 2026
…35486) Stacked on #35485. Before this PR, the `startGestureTransition` API would itself never commit its state. After the gesture releases it stops the animation in the next commit which just leaves the DOM tree in the original state. If there's an actual state change from the Action then that's committed as the new DOM tree. To avoid animating from the original state to the new state again, this is DOM without an animation. However, this means that you can't have the actual action committing be in a slightly different state and animate between the final gesture state and into the new action. Instead, we now actually keep the render tree around and commit it in the end. Basically we assume that if the Timeline was closer to the end then visually you're already there and we can commit into that state. Most of the time this will be at the actual end state when you release but if you have something else cancelling the gesture (e.g. `touchcancel`) it can still commit this state even though your gesture recognizer might not consider this an Action. I think this is ok and keeps it simple. When the gesture lane commits, it'll leave a Transition behind as work from the revert lanes on the Optimistic updates. This means that if you don't do anything in the Action this will cause another commit right after which reverts. This revert can animate the snap back. There's a few fixes needed in follow up PRs: - Fixed in #35487. ~To support unentangled Transitions we need to explicitly entangle the revert lane with the Action to avoid committing a revert followed by a forward instead of committing the forward entangled with the revert. This just works now since everything is entangled but won't work with #35392.~ - Fixed in #35510. ~This currently rerenders the gesture lane once before committing if it was already completed but blocked. We should be able to commit the already completed tree as is.~ DiffTrain build for [4028aaa](4028aaa)
github-actions bot
pushed a commit
that referenced
this pull request
Jan 16, 2026
…35486) Stacked on #35485. Before this PR, the `startGestureTransition` API would itself never commit its state. After the gesture releases it stops the animation in the next commit which just leaves the DOM tree in the original state. If there's an actual state change from the Action then that's committed as the new DOM tree. To avoid animating from the original state to the new state again, this is DOM without an animation. However, this means that you can't have the actual action committing be in a slightly different state and animate between the final gesture state and into the new action. Instead, we now actually keep the render tree around and commit it in the end. Basically we assume that if the Timeline was closer to the end then visually you're already there and we can commit into that state. Most of the time this will be at the actual end state when you release but if you have something else cancelling the gesture (e.g. `touchcancel`) it can still commit this state even though your gesture recognizer might not consider this an Action. I think this is ok and keeps it simple. When the gesture lane commits, it'll leave a Transition behind as work from the revert lanes on the Optimistic updates. This means that if you don't do anything in the Action this will cause another commit right after which reverts. This revert can animate the snap back. There's a few fixes needed in follow up PRs: - Fixed in #35487. ~To support unentangled Transitions we need to explicitly entangle the revert lane with the Action to avoid committing a revert followed by a forward instead of committing the forward entangled with the revert. This just works now since everything is entangled but won't work with #35392.~ - Fixed in #35510. ~This currently rerenders the gesture lane once before committing if it was already completed but blocked. We should be able to commit the already completed tree as is.~ DiffTrain build for [4028aaa](4028aaa)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When a View Transition might not need to update we add it to a queue. If the parent are able to be reverted, we then cancel the already started view transitions. We do this by adding an animation that hides the "old" state and remove the view transition name from the old state.
There was a bug where if you have more than one child in a
<ViewTransition>we didn't add the right suffix to the name we added in the queue so it wasn't adding an animation that hides the old state. The effect was that it playing an exit animation instead of being cancelled.