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.
Cameron McCormack on WebKit Slack mentioned a tweet that sounds like this issue:
It contains a link to an example where we fail:
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.
This particular test can be rewritten to set the easing on the keyframe to get the desired behavior:
transform: ["none", "translate(50vw)"],
easing: "cubic-bezier(.2, 1, .2, 1.5)"
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.
Then we can track the other cases with a different bug.
Actually, let's keep this bug for the general problem and create one dedicated to fixing the 2-keyframe case.
The more specific bug is bug 225301.