Bug 295003 – [css-anchor-position-1] Scrolling anchor doesn't trigger fallback when anchored box's containing block is the scroller

• Component: Layout and Rendering
• Status: NEW

[fantasai]

Overview:

In cases where the containing block of an anchored box is a scroll container that also contains the anchor, we are not triggering fallback as we scroll the box into to the edge of the containing block. WPTs assume that this is the required behavior, however.

Affected WPT Tests: http://wpt.live/css/css-anchor-position/
* anchor-scroll-position-try-*
* position-area-scrolling-00[567]
* position-try-fallbacks-003

Specification Notes:

It's not 100% clear what the correct behavior is, i.e. whether the anchored box is contained by the scroll container's outer padding edge, or by its inner (scrollable) padding edge. On the root element, only fixed-positioned boxes are contained by the scrollport edge; absolutely-positioned boxes are contained by the scrollable area (roughly speaking). So this might need some investigation.

[Radar WebKit Bug Importer]

<rdar://problem/154349365>

[fantasai]

Discussed this with Tab, we agree that the tests where the containing block is the scroller are wrong -- scrolling these should not trigger fallback. But for the tests where the containing block is an ancestor of the scroller, those should trigger fallback.

[fantasai]

Created attachment 476346 [details]
WIP

Attaching WIP. Still have a few failing tests to fix up (anchor-scroll-nested, anchor-scroll-to-sticky-002, and position-visibility-anchors-visible-change-anchor are newly failing, so I have to figure out why). But it fixes the first five anchor-scroll-position-try, and hopefully sets us up to pass the remaining ones once last-remembered-fallback is fixed, and also fixes the js-expose test.

[fantasai]

Pull request: https://github.com/WebKit/WebKit/pull/49318