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
307788
[scroll-animations] WPT test `view-timelines/contain-alignment.html` fails
https://bugs.webkit.org/show_bug.cgi?id=307788
Summary
[scroll-animations] WPT test `view-timelines/contain-alignment.html` fails
Antoine Quint
Reported
2026-02-13 03:58:51 PST
We are failing
https://wpt.fyi/results/scroll-animations/view-timelines/contain-alignment.html
.
Attachments
Add attachment
proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1
2026-02-13 03:58:57 PST
<
rdar://problem/170309501
>
Antoine Quint
Comment 2
2026-02-16 08:02:54 PST
The test has an issue: @keyframes bg { from { background-color: rgb(254, 0, 0); } to { background-color: rgb(0 254, 0); } } Note the missing comma in the `to` value. That said, once that is fixed, we still fail all of the tests at progress `0`. If I add `console.log(element.getBoundingClientRect())` within the `forEach()` and comment out the assertions, you'll notice that for the "c" element we get these values: == Firefox == left: 24 top: 141.3333282470703 width: 32 height: 42.66667175292969 == Chrome == left: 24 top: 141.3359375 width: 32 height: 42.6640625 == Safari == left: 24 top: 141.34375 width: 32 height: 42.671875 You'll notice how top/height are different in all browsers. Since Firefox doesn't yet have an implement for view timelines – at least not in the default configuration for Firefox Nightly – I can't comment on what this yields in the animation model, but for Chrome and Safari this yields the following state for the "c" element: == Chrome == anim.currentTime: -0.0038549015072670014% anim.effect.getComputedTiming().progress: 0 == Safari == anim.currentTime: -0.007709102323286032% anim.effect.getComputedTiming().progress: null I'm not sure if this is something we should fix by adding a bit more tolerance at the "before"/"after" phase threshold, allowing for `-0.007709102323286032` to round to `0` and thus yield a progress of `0`, or if it's something we should fix at the layout level when querying the element's metrics in `ViewTimeline::cacheCurrentTime()`.
Antoine Quint
Comment 3
2026-02-16 09:33:34 PST
We can solve this by adding a little tolerance when computing the current time of an animation attached to a view timeline near the 0% and 100% thresholds. We'll compute that tolerance based on a fixed point value, such as 0.1pt.
Antoine Quint
Comment 4
2026-02-16 09:46:51 PST
Pull request:
https://github.com/WebKit/WebKit/pull/58793
Antoine Quint
Comment 5
2026-02-16 11:00:30 PST
Submitted web-platform-tests pull request:
https://github.com/web-platform-tests/wpt/pull/57818
EWS
Comment 6
2026-02-16 23:58:54 PST
Committed
307693@main
(915bfc026f21): <
https://commits.webkit.org/307693@main
> Reviewed commits have been landed. Closing PR #58793 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