WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
289992
[scroll-animations] Presence of an animation with a custom property breaks font-size that depends on rem
https://bugs.webkit.org/show_bug.cgi?id=289992
Summary
[scroll-animations] Presence of an animation with a custom property breaks fo...
Roman Komarov
Reported
2025-03-18 14:10:55 PDT
Created
attachment 474617
[details]
Saved version of CodePen Steps to reproduce: 1. Open
https://codepen.io/kizu/pen/xbxWxmp
in Safari TP 215 with scroll-driven animations feature flag enabled or the attached file. 2. The text should be 1rem in size, but it very big. The conditions are rather complex, I stumbled upon this bug when testing how scroll-driven animations work in my blog. Saw this issue with my sidenotes (for example, here:
https://kizu.dev/scroll-driven-state-transfer/
), then reduced to the smallest test case I could.
Attachments
Saved version of CodePen
(20.22 KB, text/html)
2025-03-18 14:10 PDT
,
Roman Komarov
no flags
Details
Test
(435 bytes, text/html)
2025-04-01 07:36 PDT
,
Antoine Quint
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1
2025-03-25 14:11:16 PDT
<
rdar://problem/147872254
>
Antoine Quint
Comment 2
2025-04-01 07:26:45 PDT
Inspecting the animation's computed timing and computed keyframes shows nothing unexpected. And indeed, removing the custom property in the 0% keyframe fixes the rendering… but it's really unclear why that has to do with anything since a custom property that is not used for anything.
Antoine Quint
Comment 3
2025-04-01 07:28:01 PDT
It appears the issue is that we're using the computed style from the parent rather than the one set on the element itself, but only if we have this unregistered custom property set.
Antoine Quint
Comment 4
2025-04-01 07:36:43 PDT
Created
attachment 474791
[details]
Test
Antoine Quint
Comment 5
2025-04-01 07:59:41 PDT
The `animatedStyle` computed in the `applyAnimations()` lambda within `Style::TreeResolver::createAnimatedElementUpdate()` has the expected value until `applyCascadeAfterAnimation` is called.
Antoine Quint
Comment 6
2025-04-01 08:40:46 PDT
Here's the call stack when we get to the spot where we compute the value incorrectly in `Style::computeNonCalcLengthDouble()`: #0 0x00000003072c98f0 in WebCore::Style::computeNonCalcLengthDouble at /Users/antoine/Code/safari/OpenSource/Source/WebCore/style/values/primitives/StyleLengthResolution.cpp:273 #1 0x00000003043ed048 in WebCore::CSSPrimitiveValue::resolveAsLengthDouble at /Users/antoine/Code/safari/OpenSource/Source/WebCore/css/CSSPrimitiveValue.cpp:621 #2 0x00000003043ed178 in WebCore::CSSPrimitiveValue::resolveAsLength<float> at /Users/antoine/Code/safari/OpenSource/Source/WebCore/css/CSSPrimitiveValue.cpp:581 #3 0x0000000302b37b90 in WebCore::Style::BuilderCustom::applyValueFontSize at /Users/antoine/Code/safari/OpenSource/Source/WebCore/style/StyleBuilderCustom.h:1686 #4 0x0000000302b283e0 in WebCore::Style::BuilderGenerated::applyProperty at /Users/antoine/Builds/Debug/DerivedSources/WebCore/StyleBuilderGenerated.cpp:6028 #5 0x0000000307173124 in WebCore::Style::Builder::applyProperty at /Users/antoine/Code/safari/OpenSource/Source/WebCore/style/StyleBuilder.cpp:409 #6 0x00000003071928c4 in WebCore::Style::Builder::applyCascadeProperty(WebCore::Style::PropertyCascade::Property const&)::'lambda'(WebCore::SelectorChecker::LinkMatchMask)::operator()(WebCore::SelectorChecker::LinkMatchMask) const at /Users/antoine/Code/safari/OpenSource/Source/WebCore/style/StyleBuilder.cpp:264 #7 0x0000000307171b38 in WebCore::Style::Builder::applyCascadeProperty at /Users/antoine/Code/safari/OpenSource/Source/WebCore/style/StyleBuilder.cpp:268 #8 0x00000003071b7438 in void WebCore::Style::Builder::applyPropertiesImpl<(WebCore::Style::Builder::CustomPropertyCycleTracking)1>(int, int)::'lambda'(unsigned long)::operator()(unsigned long) const at /Users/antoine/Code/safari/OpenSource/Source/WebCore/style/StyleBuilder.cpp:173 #9 0x0000000307171c94 in WebCore::Style::Builder::applyPropertiesImpl<(WebCore::Style::Builder::CustomPropertyCycleTracking)1> at /Users/antoine/Code/safari/OpenSource/Source/WebCore/style/StyleBuilder.cpp:185 #10 0x0000000307171758 in WebCore::Style::Builder::applyProperties at /Users/antoine/Code/safari/OpenSource/Source/WebCore/style/StyleBuilder.cpp:152 #11 0x00000003071715b8 in WebCore::Style::Builder::applyHighPriorityProperties at /Users/antoine/Code/safari/OpenSource/Source/WebCore/style/StyleBuilder.cpp:124 #12 0x00000003071714cc in WebCore::Style::Builder::applyAllProperties at /Users/antoine/Code/safari/OpenSource/Source/WebCore/style/StyleBuilder.cpp:110 #13 0x00000003071fc314 in WebCore::Style::TreeResolver::applyCascadeAfterAnimation at /Users/antoine/Code/safari/OpenSource/Source/WebCore/style/StyleTreeResolver.cpp:922 While we correctly deal with a `1rem` value we get the incorrect `FontDescription` inside `computeUnzoomedNonCalcLengthDouble` where the value is `96px`, which is the computed value on the parent element, not the root element. I don't think animations are really a factor here, this look like a CSS bug with `rem` unit resolution.
Antoine Quint
Comment 7
2025-04-01 08:52:39 PDT
I'm not sure why we enter the `applyAnimations()` branch which calls `applyCascadeAfterAnimation()` since in this case animations have no effect at all. This was changed in
271268@main
.
Antti Koivisto
Comment 8
2025-05-19 10:23:05 PDT
Pull request:
https://github.com/WebKit/WebKit/pull/45596
EWS
Comment 9
2025-05-24 12:06:43 PDT
Committed
295395@main
(c7d5be16b583): <
https://commits.webkit.org/295395@main
> Reviewed commits have been landed. Closing PR #45596 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