Caretaker note: the failing tests are previously failing and unrelated. This is safe to merge.

@thePunderWoman any chance that b4ec3cc could be reverted as well? (as it seems it was only added for this feature)

One of my coworkers noticed that fix breaks leave animations when artificially slowing them down for testing with chrome devtools (presumably as the animation duration is now much longer than is calculated with getComputedStyle, so the fallback timeout fires before the animation completes):

@mattlewis92 We can consider that. We are planning on re-landing nested animations with a more strict scope fairly quickly. So we'll have to see if this fix still applies (it might).

This PR was merged into the repository. The changes were merged into the following branches:

• main: 999c14e
• 21.2.x: abbd879

@mattlewis92 Looks like that fix will still be necessary. We could consider removing that fallback timer in devmode, but it would mean that the behavior would be different in dev vs prod, which isn't ideal. We could also consider maybe an injection token for debug purposes only and that would only work in devmode. What do you think?

@mattlewis92 Looks like that fix will still be necessary. We could consider removing that fallback timer in devmode, but it would mean that the behavior would be different in dev vs prod, which isn't ideal. We could also consider maybe an injection token for debug purposes only and that would only work in devmode. What do you think?

I think an injection token would be great - we have our own set of internal dev tools so we could easily toggle that on and off as needed when people need to debug animations in chrome dev tools

@mattlewis92 Actually, I wonder if we can solve this by accounting for playback rate in the code that determines the longest animation length...

@mattlewis92 I think #67656 should do it.

Though it won't account for the case when we have to fallback to getComputedStyle...

@mattlewis92 I think #67656 should do it.

Though it won't account for the case when we have to fallback to getComputedStyle...

Unfortunately that doesn't seem to work, playbackRate is always set to 1 when slowing down animations:

Here was the AI answer I got when I asked about it:

  Chrome DevTools does this via the Chrome DevTools Protocol (CDP) at the
  browser engine level, bypassing the JavaScript-visible Web Animations API entirely. It uses
  the Animation.setPlaybackRate CDP command internally, so animation.playbackRate stays 1 from
  JS's perspective.

  Bottom line: there's no reliable way to detect DevTools animation slowdown from JavaScript.
  It's intentionally opaque to the page's script context.

  If you're trying to solve a specific testing problem (e.g. waiting for animations to finish,
  or skipping animations in tests), there are better approaches:

  - animation.finished — returns a Promise that resolves when the animation completes,
  regardless of playback speed
  - animation.onfinish — same idea as a callback
  - animation.ready then animation.finish()** — programmatically jump to the end
  - For tests specifically, mock/stub Animation or use Animation.prototype.finish() to skip
  animations altogether

@mattlewis92 wonderful. OK, I'll look at the devmode only injection token, and we'll name it very clearly for what it's for.

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}