[Web Animations] Using a cubic-bezier() easing with y values above 1 fails

[Antoine Quint]

This is a follow-up to bug 215826 which addressed the CSS Transition case, but the JS-originated animation case would require either a Core Animation fix or a different, as-yet unidentified workaround.

[Radar WebKit Bug Importer]

<rdar://problem/67933480>

[Antoine Quint]

Cameron McCormack on WebKit Slack mentioned a tweet that sounds like this issue:

https://twitter.com/bdc/status/1389138046545797122

It contains a link to an example where we fail:

https://cldup.com/3gYZzqJk0K.html

[Antoine Quint]

I think we could fix this particular test because it uses a single keyframe so we could set the keyframe-specific timing function in CA rather than the animation-wide one, which is the one that doesn't handle cubic() timing function values outside of the [0-1] range. But it wouldn't fix the overall issue with animation-wide timing function with multiple keyframes.

[Antoine Quint]

This particular test can be rewritten to set the easing on the keyframe to get the desired behavior:

  document.body.firstElementChild.animate({
    transform: ["none", "translate(50vw)"],
    easing: "cubic-bezier(.2, 1, .2, 1.5)"
  }, {
    duration: 1000,
    fill: "forwards",
  });

[Antoine Quint]

So the particular example mentioned in the tweet did actually regress in r260360. What we should do is disable accelerated animations when there are more than 2 keyframes and an animation-wide timing function with a y value outside of the [0-1] range, and handle the 2-keyframe case by setting the keyframe timing function, provided there is no keyframe-specific easing.

[Antoine Quint]

Then we can track the other cases with a different bug.

[Antoine Quint]

Actually, let's keep this bug for the general problem and create one dedicated to fixing the 2-keyframe case.

[Antoine Quint]

The more specific bug is bug 225301.