WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
269858
[web-animations] composed keyframe animation behaves differently in Webkit than Firefox and Chrome
https://bugs.webkit.org/show_bug.cgi?id=269858
Summary
[web-animations] composed keyframe animation behaves differently in Webkit th...
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
Details
Test
(460 bytes, text/html)
2024-03-05 10:16 PST
,
Antoine Quint
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
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
<
rdar://problem/123777133
>
Antoine Quint
Comment 4
2024-03-05 10:16:30 PST
Created
attachment 470181
[details]
Test
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
Pull request:
https://github.com/WebKit/WebKit/pull/25629
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.
Top of Page
Format For Printing
XML
Clone This Bug