Momentum scrolling follows cursor and irritates users
Reported by
jojo.rud...@gmail.com,
Nov 10 2016
|
||||
Issue descriptionGoogle Chrome 54.0.2840.71 (Official Build) (64-bit) Revision 5e302be61aa30f443d8ba24c9ece85e8f6076fb9-refs/branch-heads/2840@{#765} URLs (if applicable) : http://codepen.io/anon/pen/VmeKxw?editors=1100#0 OS version : 10.11.6 Behavior in Safari 3.x/4.x (if applicable): works Behavior in Firefox 3.x (if applicable): Behavior in Chrome for Windows: What steps will reproduce the problem? (1) Open the following URL, which contains a simple flexgrid layout with two vertically scrollable divs: http://codepen.io/anon/pen/VmeKxw?editors=1100#0 (2) Start scrolling in the right pane (below "Page Header) and while the content is still scrolling move the mouse cursor to the sidebar (left pane) (3) Observe that the right pane will stop scrolling, but the left will start scrolling with the remaining "momentum" of the initial scroll action initated on the right pane. What is the expected result? The right pane should continue scrolling. It is extremely irritating for the user to see that the pane under the cursor scrolls even though he did not initiate a scrolling action . What happens instead? The pane under the cursor begins to use "momentum scrolling".
,
Nov 14 2016
sahel@ we probably want to block this one on shipping touch pad scroll latching because fixing it should fall out of it with the current design.
,
Nov 14 2016
,
Nov 15 2016
krajshree@ your attempt to reproduce the issue looks correct to me, I agree however that there's no indication of the bug I observe in your screencast. I have attached one myself from my machine to demonstrate the issue. I have further investigated the behavior and I am now certain that the issue DOES NOT occur with the built-in trackpad/touch pad of my macbook but it DOES occur when I use my MagicMouse (attached via Bluetooth). Can you reproduce it with this info?
,
Feb 7 2017
i see something similar on a new macbook pro, but only in retina resolution. i use the cappuccino framework, that uses a scollable div to catch the scroll events. this div is dynamically hidden. when scrolling with momentum and change direction, the scrollbar advances in the wrong direction. this is probably, because after unhiding the scollable div, this element consumes the momentum leftover from the scrolling before hiding it.
,
Feb 7 2017
Duping - since this is exactly what scroll latching will fix. |
||||
►
Sign in to add a comment |
||||
Comment 1 by krajshree@chromium.org
, Nov 11 2016Components: Blink>Scroll
Labels: Needs-Feedback
1.5 MB
1.5 MB View Download