Created attachment 401827 [details]
Demo project

<rdar://problem/64329495>

I'm getting very different behavior between Firefox Nightly 79.0a1 (2020-06-13), Chrome Canary 85.0.4171.0 and Safari Technology Preview 108 with https://codepen.io/createwithflow/pen/ExPyxex. Firefox and Chrome definitely don't behave like what you have in your screen recording.

Firefox 77.0.1 and Chrome 83.0.4103.97, the stable releases, behave as shown on the video.

So, yeah… it seems like everyone has buggy behavior here in non-stable releases.

Confirmed, FF Nightly 79.0a1 (2020-06-13) and Chrome Canary 85.0.4171.0 both look like they have issues. 

Firefox Beta 78.0b6 looks good.

I was wondering if there's a better way to set up the animations. For example, waiting for the animation to be ready...

animation.ready.then(function() {
  animation.play
});

-

General question: is there a particular set of browsers I should be testing when submitting tickets?

Travis, I haven't diagnosed the issue yet to determine what is going wrong, but you can certainly write your content in a much simpler way by using a single animation and calling reverse() on it. Here's an alternative version of your index.js file:


    // Create the animation.
    const animation = document.getElementById('square').animate({
        transform: ['rotate(0deg)','rotate(180deg)'],
        offset: [ 0, 1 ],
        easing: [ 'linear' ],
    }, {
        duration: 1000,
        composite: 'add',
        fill: 'forwards'
    });

    // Let the animation be paused originally.
    animation.pause();

    document.getElementById("button").addEventListener("click", event => {
        // If the animation has not played yet, play it.
        if (animation.playState == "paused")
            animation.play();
        // Otherwise, reverse the playback direction.
        else
            animation.reverse();
    });

As for your question about testing, it's always useful to indicate known behavior difference between Safari/WebKit and other browsers as well as previous versions of Safari in case there is a regression.

Note also that Safari does not support the "composite" property.

Hey Antoine,

I agree that for this particular animation reverse would work. However, we generate some fairly complex sets of animations, and have found that setting our own reversed versions to behave more consistently. Also, without getting into the weeds, we also do some dynamic swapping of whole sets of animations. So the technique is what I was trying isolate.

I should have removed the composite add, I was iterating through some variations on the demo and testing. Forgot to delete that.

I will run some more experiments on my end.

T

You can also call .cancel() on the animations that are being replaced. I don't know if that will matter in this particular instance, but if you know an animation won't be relevant anymore, this would be a good thing to do. You can also set animation.effect.target = null to no longer apply that animation to its target element.

The change in behavior between Firefox and Firefox Nightly is due to the use of `composite: add`, which is disabled in Firefox but enabled in Firefox Nightly. Could be the same story with Chrome.

Yeah, looks like this was the same issue with Chrome Canary.
I have removed that `composite:add` line from the demo.

(In reply to Antoine Quint from comment #8)
> Note also that Safari does not support the "composite" property.

(In reply to Antoine Quint from comment #7)
> Travis, I haven't diagnosed the issue yet to determine what is going wrong,
> but you can certainly write your content in a much simpler way by using a
> single animation and calling reverse() on it. Here's an alternative version
> of your index.js file:
> 
> 
>     // Create the animation.
>     const animation = document.getElementById('square').animate({
>         transform: ['rotate(0deg)','rotate(180deg)'],
>         offset: [ 0, 1 ],
>         easing: [ 'linear' ],
>     }, {
>         duration: 1000,
>         composite: 'add',
>         fill: 'forwards'
>     });
> 
>     // Let the animation be paused originally.
>     animation.pause();
> 
>     document.getElementById("button").addEventListener("click", event => {
>         // If the animation has not played yet, play it.
>         if (animation.playState == "paused")
>             animation.play();
>         // Otherwise, reverse the playback direction.
>         else
>             animation.reverse();
>     });
> 
> As for your question about testing, it's always useful to indicate known
> behavior difference between Safari/WebKit and other browsers as well as
> previous versions of Safari in case there is a regression.

The reverse function doesn't actually work in Safari. 

You can see the browser support for the reverse function on MDN here:
https://developer.mozilla.org/en-US/docs/Web/API/Animation/reverse#:~:text=reverse()%20method%20of%20the,animation%20will%20continue%20in%20reverse.

MDN is incorrect then, reverse() works in Safari as of Safari 13.1.

Works in 13.1.1 not 13.1. You can get it here https://www.techspot.com/downloads/downloadnow/4185/?evp=e88fa7dde729eadd7478088bf9808c66&file=1

I couldn't find it on the Apple website.

Hi, just confirming that this bug still exists.

We don't support the `composite` property yet, see bug 189299. I expect this is required to get your content to behave as expected.