Bug 223175

Summary: [css-scroll-snap] Properly handle overflowing snap areas
Product: WebKit Reporter: Martin Robinson <mrobinson>
Component: CSSAssignee: Martin Robinson <mrobinson>
Status: RESOLVED DUPLICATE    
Severity: Normal CC: cmarcelo, ews-watchlist, fred.wang, jamesr, luiz, tonikitoo
Priority: P2    
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch
none
Patch
none
Patch none

Martin Robinson
Reported 2021-03-15 01:17:37 PDT
When a snap area overflows the snapper, the specification details some specific handling. From https://www.w3.org/TR/css-scroll-snap-1/#snap-overflow: If the snap area is larger than the snapport in a particular axis, then any scroll position in which the snap area covers the snapport, and the distance between the geometrically previous and subsequent snap positions in that axis is larger than size of the snapport in that axis, is a valid snap position in that axis. The UA may use the specified alignment as a more precise target for certain scroll operations (e.g. explicit paging). This implies that we keep snap area dimension around when we didn't before.
Attachments
Patch (160.12 KB, patch)
2021-03-15 04:53 PDT, Martin Robinson 		no flags
DetailsFormatted DiffDiff
Patch (77.18 KB, patch)
2021-03-15 06:04 PDT, Martin Robinson 		no flags
DetailsFormatted DiffDiff
Patch (77.64 KB, patch)
2021-03-15 09:41 PDT, Martin Robinson 		no flags
DetailsFormatted DiffDiff
Patch (77.97 KB, patch)
2021-03-16 02:41 PDT, Martin Robinson 		no flags
DetailsFormatted DiffDiff
Show Obsolete (3) View All Add attachment proposed patch, testcase, etc.
Martin Robinson
Comment 1 2021-03-15 04:53:12 PDT
Created attachment 423157 [details] Patch
Martin Robinson
Comment 2 2021-03-15 06:04:41 PDT
Created attachment 423166 [details] Patch
Martin Robinson
Comment 3 2021-03-15 09:41:56 PDT
Created attachment 423189 [details] Patch
Martin Robinson
Comment 4 2021-03-16 02:41:50 PDT
Created attachment 423311 [details] Patch
Martin Robinson
Comment 5 2021-03-16 06:00:08 PDT
Here's some background on these changes as they are a bit larger and more complicated than normal: Before this change when snap points were calculated after a layout and a ScrollSnapOffsetsInfo was created with both the offsets of the snap points and a set of ranges of offsets where no snapping occurred. These ranges were useful because it made it simple to determine if a particular offset was subject to snapping. With the implementation of this part of the specification, the range-based approach is not as suitable because snap areas (which may overlap) now affect whether or not a scroll will snap to a snap point. Instead, this change take a lazier approach. During scrolling, we walk through each potential snap offset and look at the associated snap area. This information to determine if the destination scroll offset falls onto a snap area that overflows the snapport or if it is subject to proximity snapping.
Martin Robinson
Comment 6 2021-03-17 03:15:46 PDT
*** This bug has been marked as a duplicate of bug 223021 ***
Note You need to log in before you can comment on or make changes to this bug.