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

• Status: NEW
• Component: Layout and Rendering

[jonjohnjohnson]

[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.

[jonjohnjohnson]

Just offering a quick video of the bug in the test case, showing how a "scrollend" position is stuck that is far beyond where it should be when using scroll-snap in conjunction with child elements that have dimensions set based upon % of the snapport or viewport and the snapport resizes.

http://cl.ly/dba9a5c11a85

[jonjohnjohnson]

Chiming in, letting you know that the blink implementation doesn't have this bug when reproducing this issues steps. They don't keep a "snapped" position that is too from the scroll start edge when the scroll(Height/Width) shrinks in a snapport.

Any thoughts here?

[jonjohnjohnson]

Also here is a video of the "aside" I described in my initial description.
http://cl.ly/b531967faeb5
Showing an extra subpixel snap point that resolves if you scroll passed the scrollend, but not if you scroll towards the last desired snap position but not passed the end.

[Radar WebKit Bug Importer]

<rdar://problem/47182264>

[Martin Robinson]

I am still able to reproduce this bug.