Bug 270064 – [css-scroll-snap] Ignores scroll-snap-type: mandatory on JS-triggered scrolling

• Status: NEW
• Component: Scrolling

[Casey Carroll]

Created attachment 470046 [details]
Video of scenario described in bug report

WebKit ignores a scroll container's scroll-snap-type: mandatory and child's scroll-snap-align when scrolling is invoked via JS. i.e. Element.scrollBy(), Element.scrollTo(). 

Given a 300px container with 100% width children overflowing in the inline direction, each with scroll-snap-align set,
When container.scrollBy(150, 0) is called the container scrolls 150px and does not snap to the next child nor return to the previous child
As a result, The scroller's x coordinates stick exactly at 150px between the two items despite the scroll-snap configuration.  

Chrome and Firefox will snap to the next item, even if the x-coord parameter is set to a minimum, 1 pixel. 

Essentially, when a scrolling function is called in WebKit, it scrolls to the exact coordinates but does not apply scroll snapping. This bug does not apply to scrolling initiated by touch, trackpad and mouse gestures. 

Example: https://codepen.io/caseycarroll42/pen/poYvOJm

[Anthony Ricaud]

This looks similar to https://bugs.webkit.org/show_bug.cgi?id=241737

[Radar WebKit Bug Importer]

<rdar://problem/123988594>

[Karl Dubost]

Yes, I think Anthony is right. I let Simon duplicates it if he thinks that's the case.

[Anthony Ricaud]

Taking another look at bug 241737, I wouldn't say they are duplicates anymore. This bug is using `scrollBy()` and `scrollTo()` and not getting the snapping effect wanted.

Whereas bug 241737 is using `scrollLeft` and getting an undesired snapping effect.