Bug 299823 – REGRESSION(294049@main): starting an animation via el.animate().reverse only works every other time

• Component: Animations
• Status: RESOLVED FIXED

[Caleb Hearon]

jsfiddle: https://jsfiddle.net/n962tryh/

- Safari 18 animates the div every button click
- Safari 26 animates the 1st, 3rd, 5th... times
- Firefox animates every click
- Chrome animates every click

I don't know Web Animations well enough to know what should happen, or if this is an under-specified area, but it broke our app. It's possibly Intel-specific: my colleague was not able to reproduce on Apple Silicon

[Stephen Thomas]

Can confirm with Safari 26.0.1 on Sequoia as well. Versions 15.7 and 15.7.1. But only on a Mini with an Intel CPU. No bug observed on a different M4 Mini.

[Radar WebKit Bug Importer]

<rdar://problem/162067522>

[Antoine Quint]

It's not Intel-specific, I can reproduce this with Safari 26.0.1 on macOS Tahoe 26.0.1 (25A362). Will find the regression point.

[Antoine Quint]

It appears to already have been broken in 294709@main.

[Antoine Quint]

The regression range is https://commits.webkit.org/compare/294072@main...294026@main. This most likely this regressed with 294049@main, the fix for bug 290993.

[Antoine Quint]

Oddly enough this does not reproduce with the HTML and JS code pasted into an HTML file. But it does within the iframe on jsfiddle.

[Antoine Quint]

I expect this is going to be something to do with throttling.

[Antoine Quint]

There's really something specific to jsfiddle here. If I call `document.getAnimations()[0].cancel()` after the page is loaded, the bug stops reproducing.

[Antoine Quint]

So there's some bad interaction between the CSS Animation applied to the "AN" avatar in the page's top bar above the HTML and the animation in the content. Will try to reduce this, but it's quite odd.

[Antoine Quint]

This can be reduced to a host document running a constant background-color animation while a child document, hosted via an <iframe>, animates using the reverse() method.

[Antoine Quint]

I think this is due to timers being throttled in iframes and the call to `AnimationTimelinesController::processPendingAnimations()` taking longer than expected to run, only after the next animation resolution, and thus the animation never getting a committed start time.

[Stephen Thomas]

Just a note to add that we encountered the bug in our application, which does not use Iframes. So it is  NOT strictly an iframe issue

[Antoine Quint]

So far I've only managed to reproduce the issue in the context of iframes where timing is different… but since this is a timing issue, I expect this may occur depending on the JavaScript performance. If you can make a reduction that does not involve iframes, it would be good to see it as well.

[Antoine Quint]

Pull request: https://github.com/WebKit/WebKit/pull/52233

[Stephen Thomas]

Looks like the issue has been found, but for completeness, unfortunately our application code is too complex to share easily (and is also proprietary) but the fact that we could easily reproduce on Intel clients but not Apple Silicon clients definitely supports the idea that it's timing/performance related. I can share the workaround we deployed, if that's helpful.

Broken:

```
const animation = el.animate(keyframes, {duration: 200});
animation.addEventListener("finish", done);
if (reverse) animation.reverse();
```

Works:

```
if (reverse) keyframes.reverse();
const animation = el.animate(keyframes, {duration: 200});
animation.addEventListener("finish", done);
```

[EWS]

Committed 301414@main (841997317f49): <https://commits.webkit.org/301414@main>

Reviewed commits have been landed. Closing PR #52233 and removing active labels.