Add the suffix to cancelled view transition names by sebmarkbage · Pull Request #35485 · react/react

sebmarkbage · 2026-01-12T03:49:54Z

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.

react-sizebot · 2026-01-12T03:53:36Z

Comparing: 5aec1b2...b551a86

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-stable/react-dom/cjs/react-dom.production.js	=	6.84 kB	6.84 kB	+0.11%	1.88 kB	1.88 kB
oss-stable/react-dom/cjs/react-dom-client.production.js	+0.02%	607.60 kB	607.71 kB	=	107.53 kB	107.54 kB
oss-experimental/react-dom/cjs/react-dom.production.js	=	6.84 kB	6.84 kB	+0.11%	1.88 kB	1.88 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js	+0.02%	666.83 kB	666.94 kB	+0.01%	117.42 kB	117.43 kB
facebook-www/ReactDOM-prod.classic.js	+0.02%	692.91 kB	693.02 kB	=	121.92 kB	121.93 kB
facebook-www/ReactDOM-prod.modern.js	+0.02%	683.34 kB	683.45 kB	=	120.31 kB	120.31 kB

Significant size changes

Includes any change greater than 0.2%:

(No significant changes)

Generated by 🚫 dangerJS against b551a86

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)

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](react@4a3d993)

…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.~

…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)

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](react@4a3d993)

sebmarkbage · 2026-01-12T03:49:54Z

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.

react-sizebot · 2026-01-12T03:53:36Z

Comparing: 5aec1b2...b551a86

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-stable/react-dom/cjs/react-dom.production.js	=	6.84 kB	6.84 kB	+0.11%	1.88 kB	1.88 kB
oss-stable/react-dom/cjs/react-dom-client.production.js	+0.02%	607.60 kB	607.71 kB	=	107.53 kB	107.54 kB
oss-experimental/react-dom/cjs/react-dom.production.js	=	6.84 kB	6.84 kB	+0.11%	1.88 kB	1.88 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js	+0.02%	666.83 kB	666.94 kB	+0.01%	117.42 kB	117.43 kB
facebook-www/ReactDOM-prod.classic.js	+0.02%	692.91 kB	693.02 kB	=	121.92 kB	121.93 kB
facebook-www/ReactDOM-prod.modern.js	+0.02%	683.34 kB	683.45 kB	=	120.31 kB	120.31 kB

Significant size changes

Includes any change greater than 0.2%:

(No significant changes)

Generated by 🚫 dangerJS against b551a86

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)

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](react@4a3d993)

…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.~

…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)

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](react@4a3d993)

sebmarkbage · 2026-01-12T03:49:54Z

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.

react-sizebot · 2026-01-12T03:53:36Z

Comparing: 5aec1b2...b551a86

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-stable/react-dom/cjs/react-dom.production.js	=	6.84 kB	6.84 kB	+0.11%	1.88 kB	1.88 kB
oss-stable/react-dom/cjs/react-dom-client.production.js	+0.02%	607.60 kB	607.71 kB	=	107.53 kB	107.54 kB
oss-experimental/react-dom/cjs/react-dom.production.js	=	6.84 kB	6.84 kB	+0.11%	1.88 kB	1.88 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js	+0.02%	666.83 kB	666.94 kB	+0.01%	117.42 kB	117.43 kB
facebook-www/ReactDOM-prod.classic.js	+0.02%	692.91 kB	693.02 kB	=	121.92 kB	121.93 kB
facebook-www/ReactDOM-prod.modern.js	+0.02%	683.34 kB	683.45 kB	=	120.31 kB	120.31 kB

Significant size changes

Includes any change greater than 0.2%:

(No significant changes)

Generated by 🚫 dangerJS against b551a86

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)

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](react@4a3d993)

…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.~

…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)

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](react@4a3d993)

sebmarkbage · 2026-01-12T03:49:54Z

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.

react-sizebot · 2026-01-12T03:53:36Z

Comparing: 5aec1b2...b551a86

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-stable/react-dom/cjs/react-dom.production.js	=	6.84 kB	6.84 kB	+0.11%	1.88 kB	1.88 kB
oss-stable/react-dom/cjs/react-dom-client.production.js	+0.02%	607.60 kB	607.71 kB	=	107.53 kB	107.54 kB
oss-experimental/react-dom/cjs/react-dom.production.js	=	6.84 kB	6.84 kB	+0.11%	1.88 kB	1.88 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js	+0.02%	666.83 kB	666.94 kB	+0.01%	117.42 kB	117.43 kB
facebook-www/ReactDOM-prod.classic.js	+0.02%	692.91 kB	693.02 kB	=	121.92 kB	121.93 kB
facebook-www/ReactDOM-prod.modern.js	+0.02%	683.34 kB	683.45 kB	=	120.31 kB	120.31 kB

Significant size changes

Includes any change greater than 0.2%:

(No significant changes)

Generated by 🚫 dangerJS against b551a86

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)

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](react@4a3d993)

…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.~

…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)

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](react@4a3d993)

sebmarkbage · 2026-01-12T03:49:54Z

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.

react-sizebot · 2026-01-12T03:53:36Z

Comparing: 5aec1b2...b551a86

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-stable/react-dom/cjs/react-dom.production.js	=	6.84 kB	6.84 kB	+0.11%	1.88 kB	1.88 kB
oss-stable/react-dom/cjs/react-dom-client.production.js	+0.02%	607.60 kB	607.71 kB	=	107.53 kB	107.54 kB
oss-experimental/react-dom/cjs/react-dom.production.js	=	6.84 kB	6.84 kB	+0.11%	1.88 kB	1.88 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js	+0.02%	666.83 kB	666.94 kB	+0.01%	117.42 kB	117.43 kB
facebook-www/ReactDOM-prod.classic.js	+0.02%	692.91 kB	693.02 kB	=	121.92 kB	121.93 kB
facebook-www/ReactDOM-prod.modern.js	+0.02%	683.34 kB	683.45 kB	=	120.31 kB	120.31 kB

Significant size changes

Includes any change greater than 0.2%:

(No significant changes)

Generated by 🚫 dangerJS against b551a86

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)

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](react@4a3d993)

…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.~

…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)

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](react@4a3d993)

sebmarkbage · 2026-01-12T03:49:54Z

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.

react-sizebot · 2026-01-12T03:53:36Z

Comparing: 5aec1b2...b551a86

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-stable/react-dom/cjs/react-dom.production.js	=	6.84 kB	6.84 kB	+0.11%	1.88 kB	1.88 kB
oss-stable/react-dom/cjs/react-dom-client.production.js	+0.02%	607.60 kB	607.71 kB	=	107.53 kB	107.54 kB
oss-experimental/react-dom/cjs/react-dom.production.js	=	6.84 kB	6.84 kB	+0.11%	1.88 kB	1.88 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js	+0.02%	666.83 kB	666.94 kB	+0.01%	117.42 kB	117.43 kB
facebook-www/ReactDOM-prod.classic.js	+0.02%	692.91 kB	693.02 kB	=	121.92 kB	121.93 kB
facebook-www/ReactDOM-prod.modern.js	+0.02%	683.34 kB	683.45 kB	=	120.31 kB	120.31 kB

Significant size changes

Includes any change greater than 0.2%:

(No significant changes)

Generated by 🚫 dangerJS against b551a86

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)

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](react@4a3d993)

…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.~

…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)

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](react@4a3d993)

sebmarkbage · 2026-01-12T03:49:54Z

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.

react-sizebot · 2026-01-12T03:53:36Z

Comparing: 5aec1b2...b551a86

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-stable/react-dom/cjs/react-dom.production.js	=	6.84 kB	6.84 kB	+0.11%	1.88 kB	1.88 kB
oss-stable/react-dom/cjs/react-dom-client.production.js	+0.02%	607.60 kB	607.71 kB	=	107.53 kB	107.54 kB
oss-experimental/react-dom/cjs/react-dom.production.js	=	6.84 kB	6.84 kB	+0.11%	1.88 kB	1.88 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js	+0.02%	666.83 kB	666.94 kB	+0.01%	117.42 kB	117.43 kB
facebook-www/ReactDOM-prod.classic.js	+0.02%	692.91 kB	693.02 kB	=	121.92 kB	121.93 kB
facebook-www/ReactDOM-prod.modern.js	+0.02%	683.34 kB	683.45 kB	=	120.31 kB	120.31 kB

Significant size changes

Includes any change greater than 0.2%:

(No significant changes)

Generated by 🚫 dangerJS against b551a86

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)

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](react@4a3d993)

…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.~

…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)

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](react@4a3d993)

sebmarkbage · 2026-01-12T03:49:54Z

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.

react-sizebot · 2026-01-12T03:53:36Z

Comparing: 5aec1b2...b551a86

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-stable/react-dom/cjs/react-dom.production.js	=	6.84 kB	6.84 kB	+0.11%	1.88 kB	1.88 kB
oss-stable/react-dom/cjs/react-dom-client.production.js	+0.02%	607.60 kB	607.71 kB	=	107.53 kB	107.54 kB
oss-experimental/react-dom/cjs/react-dom.production.js	=	6.84 kB	6.84 kB	+0.11%	1.88 kB	1.88 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js	+0.02%	666.83 kB	666.94 kB	+0.01%	117.42 kB	117.43 kB
facebook-www/ReactDOM-prod.classic.js	+0.02%	692.91 kB	693.02 kB	=	121.92 kB	121.93 kB
facebook-www/ReactDOM-prod.modern.js	+0.02%	683.34 kB	683.45 kB	=	120.31 kB	120.31 kB

Significant size changes

Includes any change greater than 0.2%:

(No significant changes)

Generated by 🚫 dangerJS against b551a86

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)

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](react@4a3d993)

…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.~

…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)

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](react@4a3d993)

sebmarkbage requested review from jackpope and rickhanlonii January 12, 2026 03:49

meta-claBot added the CLA Signed label Jan 12, 2026

Add the suffix to cancelled view transition names
b551a86

sebmarkbage force-pushed the fixcancelvt branch from 29a3ede to b551a86Compare January 12, 2026 03:50

github-actionsBot added the React Core Team Opened by a member of the React Core Team label Jan 12, 2026

sebmarkbage mentioned this pull request Jan 12, 2026
Commit the Gesture lane if a gesture ends closer to the target state #35486
Merged

jackpope approved these changes Jan 14, 2026
View reviewed changes

sebmarkbage merged commit 4a3d993 into react:mainJan 14, 2026
234 checks passed

nextjs-bot mentioned this pull request Jan 14, 2026
Upgrade React from 3e1abcc8-20260113 to 4a3d993e-20260114vercel/next.js#88547
Merged

rubennorte mentioned this pull request Jun 5, 2026
Upgrade React and renderers from 19.2.3 to 19.2.7 react/react-native#57089
Closed