Bug 295003
| Summary: | [css-anchor-position-1] Scrolling anchor doesn't trigger fallback when anchored box's containing block is the scroller | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | fantasai <fantasai.bugs> |
| Component: | Layout and Rendering | Assignee: | fantasai <fantasai.bugs> |
| Status: | NEW | ||
| Severity: | Normal | CC: | bfulgham, kiet.ho, simon.fraser, webkit-bug-importer, zalan |
| Priority: | P2 | Keywords: | InRadar |
| Version: | WebKit Local Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Bug Depends on: | |||
| Bug Blocks: | 289743, 291856 | ||
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.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
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.