Bug 269858

Summary: [web-animations] composed keyframe animation behaves differently in Webkit than Firefox and Chrome
Product: WebKit Reporter: Adam Argyle <argyle>
Component: AnimationsAssignee: Antoine Quint <graouts>
Status: RESOLVED FIXED    
Severity: Normal CC: ahmad.saleem792, dino, graouts, graouts, karlcow, webkit-bug-importer
Priority: P2 Keywords: BrowserCompat, InRadar
Version: Safari 17   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
a "shake in" animation is shown across Firefox, Chrome and Safari
none
Test none

Adam Argyle
Reported 2024-02-21 11:35:28 PST
Created attachment 470002 [details] a "shake in" animation is shown across Firefox, Chrome and Safari This was reported by a user recently, which may mean it's a regression? Was discovered here, at the "shake in" combined keyframe animation example: https://open-props.style/#animations Here's a reduced Codepen that also reproduces the issue; Safari does no vertical transformations: https://codepen.io/argyleink/pen/rNRgMLa/6c8023e5046030c7b5cdce32a7d6c33a A video is also attached showing the 3 major browsers attempting the same animation.
Attachments
a "shake in" animation is shown across Firefox, Chrome and Safari (1.20 MB, video/mp4)
2024-02-21 11:35 PST, Adam Argyle
no flags
Test (460 bytes, text/html)
2024-03-05 10:16 PST, Antoine Quint
no flags
Ahmad Saleem
Comment 1 2024-02-21 13:31:21 PST
I am able to reproduce this bug in Safari Technology Preview and don't get up / down shake using Codepen from Comment 0. Both Firefox Nightly 125 and Chrome Canary 123 match each other and have shake. Adding 'BrowserCompat' tag. I will update my test result with WebKit ToT once I have my local build compiled / finished. :-)
Ahmad Saleem
Comment 2 2024-02-21 13:47:14 PST
Reproducible on WebKit ToT (275126@main -- Minibrowser Release).
Radar WebKit Bug Importer
Comment 3 2024-02-28 11:36:20 PST
Antoine Quint
Comment 4 2024-03-05 10:16:30 PST
Antoine Quint
Comment 5 2024-03-05 10:19:03 PST
So here composition occurs from not providing an explicit keyframe on either transform animations running on the same element. This works fine with threaded animation resolution enabled.
Antoine Quint
Comment 6 2024-03-08 06:19:59 PST
The problem is that when we encounter animations with implicit keyframes, we resolve those using the underlying style. In this case, this is the wrong approach because the underlying style should be used for the first of the two transform animations only, and the second animation ought to use the output of the first animation to use as the underlying value. We may have to opt out of accelerating animations in this situation, at least with the existing codepath. Thankfully, the threaded animation resolution codepath handles this correctly.
Antoine Quint
Comment 7 2024-03-08 09:05:23 PST
EWS
Comment 8 2024-03-09 17:54:46 PST
Committed 275887@main (e9e959922d19): <https://commits.webkit.org/275887@main> Reviewed commits have been landed. Closing PR #25629 and removing active labels.
Note You need to log in before you can comment on or make changes to this bug.