[Webkit-unassigned] [Bug 184774] New: [scroll-snap] changes in scrollWidth/scrollHeight of "snapping" container can cause invalid/stuck scroll positions

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=184774

            Bug ID: 184774
           Summary: [scroll-snap] changes in scrollWidth/scrollHeight of
                    "snapping" container can cause invalid/stuck scroll
                    positions
           Product: WebKit
           Version: Safari Technology Preview
          Hardware: Macintosh
                OS: macOS 10.12
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Layout and Rendering
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: hi at jonjohnjohnson.com
                CC: bfulgham at webkit.org, simon.fraser at apple.com,
                    zalan at apple.com

[scroll-snap] changes in scrollWidth/scrollHeight of "snapping" container can cause invalid/stuck scroll positions

Steps:

1. Navigate to -> http://output.jsbin.com/qugurer/5
2. Make sure your browser window can be resized to be more narrow.
4. Scroll any/all of the "rows" horizontally, all the way to their "end" scroll position.
5. Resize your browser window to be more narrow.
6. Notice how each row that was previously scrolled to their end is now scrolled/stuck to a scroll position that is beyond that scroll containers ability to scroll.
7. Once another scroll even happens for that scroll container, the bug disappears and the scroll position jumps back.

Note, the use of vw units to set the width of the contents in these scroll boxes.

Expected:
When the dimensions of a scroll snapping container change, scroll positions should be held within the valid scroll positions from the beginning or end the scroll box within the scroll container.

Observed:
Invalid scroll positions. Notice if you remove the "scroll-snap-type" property declaration for the horizontal scrollers and repeat the steps above, their is no bug. So something special is "locking" the last snap position through the elements resizing.

As an aside...

There sometimes seems to be an extra "last snapped" position created when sub pixel values make what would be the last element that should be snapped to off by less than a css pixel.

To observe this, navigate to the testcase url again and set your browser windows width to 375px (common iPhone iOS Safari width) and scroll the 6th row beyond it's end. Notice the red background show through the row as much as a half pixels width? Now scroll back to the left a few pixels and see the snap position align to the end of the block within the row, not showing the red sliver. There are two snap positions being honored a half pixel apart. Just something else that MIGHT be buggy about how the way the end of a scroll snapping container snaps.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180419/e2c2897e/attachment.html>