Created attachment 396484 [details] Safari (incorrect): Left box is animated with `top`. Right box is animated using `transform`. Both have the same keyframe easings. Overview: Animation effect definitions may include easing properties in each keyframe, like so: element.animate( [ { top: "0px", easing: "step-start" }, { top: "100px", easing: "step-start" }, { top: "0px", } ], 1000 ); These should define the timing of interpolations between frames, but the property is ignored when the keyframes include transforms. Steps to reproduce: Define an animation effect using a) transforms and b) easings per-keyframe. An example is hosted here: https://webkit-animation-easing.glitch.me/easing.html element.animate( [ { transform: "translateY(0px)", easing: "step-start" }, { transform: "translateY(100px)", easing: "step-start" }, { transform: "translateY(0px)", } ], 1000 ); Actual Results: See in example URL that keyframe easings are not respected for the element whose `transform` is animated. Expected results: Animation effect should respect easings, like it does for the element whose `top` is animated. Platform: Safari Version 13.1 (15609.1.20.111.8) macOS 10.15.4 (19E266) Additional Information: Attached video showing actual result.
Created attachment 396485 [details] (ignore this attachment, it was added accidentally)
<rdar://problem/61800424>
Created attachment 396488 [details] Chrome (correct): Left box is animated with `top`. Right box is animated using `transform`. Both have the same keyframe easings.
We don't support the "steps" family of timing functions for accelerated animations. We should opt out of the accelerated path in that case.
Created attachment 396538 [details] Test showing CSS and Web Animations for top and transform Attaching a new test case that shows how CSS Animations behave correctly but not a JS-originated animation.
I think we're not setting the per-keyframe timing functions in KeyframeEffect::updateBlendingKeyframes().
Created attachment 396965 [details] Patch
Committed r260360: <https://trac.webkit.org/changeset/260360>
Comment on attachment 396965 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=396965&action=review > LayoutTests/webanimations/transform-animation-with-steps-timing-function-not-accelerated.html:23 > + animation.ready.then(() => { > + // We wait for two frames to ensure an accelerated animation would have been committed. > + requestAnimationFrame(() => { > + requestAnimationFrame(() => { > + assert_equals(internals.acceleratedAnimationsForElement(target).length, 0, "The animation's target has no accelerated animation."); > + t.done(); > + }); > + }); > + }); This would read better with await
*** Bug 212686 has been marked as a duplicate of this bug. ***
This caused bug 213495.