STR: 1. Load attached testcase. 2. Try clicking the buttons to see which ones cause the scrollable div to advance its position. ACTUAL RESULTS: The buttons up-to-and-including `200` are ineffective. You have to set scrollLeft to `200` in order to get the div to scroll. EXPECTED RESULTS: The buttons at `51` and greater should all generate a scroll. Firefox gives ACTUAL REULTS (and does so in Nightlies going back as far as we have support for `scroll-snap-align` from bug 1373835). Chromium and WebKit give EXPECTED RESULTS. I'm not an expert on scroll-snapping; "expected results" are based on comparison to other browsers and my intuition based on the fact that the scrollable area has a `scrollLeftMax` of `100` (which is the `scrollLeft` that we arrive at when Firefox does actually scroll here). This testcase is reduced from the apple store website example in bug 1850485, and I think this might be the root of the issue there. The scrolling in that bug happens dynamically via several steps (starting with a transitioned `transform`), but I suspect it ends up tripping this bug towards the end of the scripted scroll operation and inadvertently resetting the scroll position as a result. hiro, could you take a look?
Bug 1905247 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
STR: 1. Load attached testcase. 2. Try clicking the buttons to see which ones cause the scrollable div to advance its position. ACTUAL RESULTS: The buttons up-to-and-including `200` are ineffective. You have to set scrollLeft to something beyond `200` in order to get the div to scroll. EXPECTED RESULTS: The buttons at `51` and greater should all generate a scroll. Firefox gives ACTUAL REULTS (and does so in Nightlies going back as far as we have support for `scroll-snap-align` from bug 1373835). Chromium and WebKit give EXPECTED RESULTS. I'm not an expert on scroll-snapping; "expected results" are based on comparison to other browsers and my intuition based on the fact that the scrollable area has a `scrollLeftMax` of `100` (which is the `scrollLeft` that we arrive at when Firefox does actually scroll here). This testcase is reduced from the apple store website example in bug 1850485, and I think this might be the root of the issue there. The scrolling in that bug happens dynamically via several steps (starting with a transitioned `transform`), but I suspect it ends up tripping this bug towards the end of the scripted scroll operation and inadvertently resetting the scroll position as a result. hiro, could you take a look?