WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
222939
[Web Animations] setKeyframes does not preserve animation's current offset
https://bugs.webkit.org/show_bug.cgi?id=222939
Summary
[Web Animations] setKeyframes does not preserve animation's current offset
Liam DeBeasi
Reported
2021-03-08 13:37:41 PST
Created
attachment 422613
[details]
Code reproduction When using setKeyframes() on an animation, WebKit does not preserve the animation's current offset. For example, if an animation is at 100% progress and setKeyframes() is called, WebKit will reset the animation's progress to 0%. Steps to reproduce: 1. Open attached code reproduction in either Safari for iOS or macOS. 2. Observe that a blue square translates from left to right and then stops. 3. Press "Update Keyframes". You should notice that the square jumps back to the left/starting position. Expected Behavior: I would expect that after pressing "Update Keyframes" that the square stays at its ending position. Actual Behavior: The square is reset back to its starting position. Other Information: - I can reproduce this in STP 121 and iOS 14.5, though I can reproduce this on stable releases as well. - Both Chrome and Firefox preserve the animation's current offset as expected. - This is only an issue if "fill: 'both'" is set on the animation.
Attachments
Code reproduction
(1.20 KB, text/html)
2021-03-08 13:37 PST
,
Liam DeBeasi
no flags
Details
Simplified testcase
(608 bytes, text/html)
2021-03-09 01:22 PST
,
Antoine Quint
no flags
Details
Patch
(7.56 KB, patch)
2021-03-09 08:23 PST
,
Antoine Quint
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1
2021-03-09 01:11:34 PST
<
rdar://problem/75207793
>
Antoine Quint
Comment 2
2021-03-09 01:22:53 PST
Created
attachment 422677
[details]
Simplified testcase Simplified the test case to not involve accelerated animations and not require interaction.
Antoine Quint
Comment 3
2021-03-09 01:24:53 PST
Interestingly, the output of animation.effect.getComputedTiming() shows the expected values, so I think this is purely about presentation and not the animation model.
Antoine Quint
Comment 4
2021-03-09 07:26:36 PST
What happens is that calling seyKeyframes() empties m_blendingKeyframes and we rely on that to have KeyframeEffect::animatedProperties() return the effect's properties inside of DocumentTimeline::animationCanBeRemoved(). Because we are not aware of any animated properties, the animation is marked as removable and retired from the keyframe effect stack, and thus it is no longer invalidated during the ensuing style update. I think all this needs is for KeyframeEffect::animatedProperties() to return properties from the parsed keyframes until the next style update when m_blendingKeyframes will be reset.
Antoine Quint
Comment 5
2021-03-09 08:23:56 PST
Created
attachment 422700
[details]
Patch
EWS
Comment 6
2021-03-09 12:09:54 PST
Committed
r274165
: <
https://commits.webkit.org/r274165
> All reviewed patches have been landed. Closing bug and clearing flags on
attachment 422700
[details]
.
Liam DeBeasi
Comment 7
2021-03-10 07:41:27 PST
That was fast, thank you! I will keep an eye out for this fix whenever it lands in STP.
Antoine Quint
Comment 8
2021-03-10 07:52:27 PST
(In reply to Liam DeBeasi from
comment #7
)
> That was fast, thank you! I will keep an eye out for this fix whenever it > lands in STP.
Thanks for filing with a great reduction, it really helps. It won't be in the immediate next STP release but in the one after that.
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