[css-scroll-snap] Programmatic scrolling to snap position isn't interrupted/cancelled by anchor link scrolling, unlike when snap-snap-type is none
Reported by
h...@jonjohnjohnson.com,
Dec 19
|
|||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3642.0 Safari/537.36 Steps to reproduce the problem: 1. Go to https://vault.jonjohnjohnson.com/examples/scrolltabs/ 2. Scroll horizontally between snapped alignments. 3. Before scrolling finishes snapping animation, attempt to click a tab to different snap alignment. 4. Notice how the anchor linked click of the tab will not cancel snapping animation, though it changes the hash in the url, while not aligning to the targeted element. What is the expected behavior? Scroll snapping should be cancellable, just as if scroll container did not have a snapport, by means of anchor links. What went wrong? Here is a video http://cl.ly/071a913b57ff Again, if scroll-snapping isn't set, then the inertia of a scroll gesture is cancellable and the new scroll position will match the url as well as the alignment of targeted element when an anchor link is clicked, regardless of scroll-behavior set to auto or smooth. Did this work before? N/A Chrome version: 73.0.3642.0 Channel: dev OS Version: OS X 10.12.6 Flash Version:
,
Dec 20
,
Dec 20
,
Jan 6
sunyunjia@chromium.org I've noticed there is a possible tangential issue, but not sure it's worth opening another ticket... If you open the test case, and simple click twice in quick succession on the "2" tab, the first click will cause smooth scrolling to start moving towards the correct target, but the second click will cancel the scrolling and instead let the "snapping" smoothly scroll back to what I'm guessing is the nearest snap position? All the while still correctly altering the target in the url. Let me know if I should report this separately or if it's encapsulated here? |
|||
►
Sign in to add a comment |
|||
Comment 1 by swarnasree.mukkala@chromium.org
, Dec 20