307788 2026-02-13 03:58:51 -0800 [scroll-animations] WPT test `view-timelines/contain-alignment.html` fails 2026-03-06 04:12:29 -0800 1 1 1 Unclassified WebKit Animations WebKit Nightly Build Unspecified Unspecified RESOLVED FIXED https://github.com/web-platform-tests/wpt/pull/57818 InRadar P2 Normal --- 307797 1 graouts graouts graouts karlcow webkit-bug-importer oldest_to_newest 2181243 0 graouts 2026-02-13 03:58:51 -0800 We are failing https://wpt.fyi/results/scroll-animations/view-timelines/contain-alignment.html. 2181244 1 webkit-bug-importer 2026-02-13 03:58:57 -0800 <rdar://problem/170309501> 2182074 2 graouts 2026-02-16 08:02:54 -0800 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()`. 2182103 3 graouts 2026-02-16 09:33:34 -0800 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. 2182106 4 graouts 2026-02-16 09:46:51 -0800 Pull request: https://github.com/WebKit/WebKit/pull/58793 2182127 5 graouts 2026-02-16 11:00:30 -0800 Submitted web-platform-tests pull request: https://github.com/web-platform-tests/wpt/pull/57818 2182323 6 ews-feeder 2026-02-16 23:58:54 -0800 Committed 307693@main (915bfc026f21): <https://commits.webkit.org/307693@main> Reviewed commits have been landed. Closing PR #58793 and removing active labels. 2187748 7 ews-feeder 2026-03-06 04:12:29 -0800 Committed 305413.411@safari-7624-branch (57e7bb615f1b): <https://commits.webkit.org/305413.411@safari-7624-branch> Reviewed commits have been landed. Closing PR #4623 and removing active labels.