Issue metadata
Sign in to add a comment
|
Scrolling bug with mouse wheel when topping a scrollable element
Reported by
guillaum...@gmail.com,
Sep 11
|
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.92 Safari/537.36 Steps to reproduce the problem: 1. Navigate to http://swimlane.github.io/ngx-datatable/#virtual-scroll 2. Move your cursor hover the list (hover the items). 3. Repeat the following steps until trigger the issue is triggered. 3.1 Give two full swipes to the mouse wheel to scroll up. 3.2 Give a third of a swipe to the mouse wheel to scroll down a bit. If while you were swiping, the list was still scrolling down instead of the whole page, then try again from step 3.1. My method is not perfect, I'm not sure exactly what conditions are required. The bug only triggers if you're topping the list when you're scrolling up at step 3.1. It will usually take me between 1 and 5 tries before triggering it. What is the expected behavior? The whole document is scrolling, instead of the list's content. What went wrong? Scrolling the list worked until it stopped after topping the list. Did this work before? Yes 68 Does this work in other browsers? Yes Chrome version: 69.0.3497.92 Channel: stable OS Version: 10.0 Flash Version: I think it worked in v68, but I couldn't be certain. This is a temporary repro, I'll try to make a smaller test case soon. In the performance profile of the repro, I'm seeing "Event(scroll)" in yellow when it's scrolling the list, then only "Event(gesturescrollupdate)" from the moment it starts scrolling the whole page. Does it help?
,
Sep 11
,
Sep 11
I noticed that I needed to avoid moving the mouse when using the mouse wheel to reproduce the bug.
,
Sep 11
,
Sep 12
Hi guillaume.dube.girard@: I'm having trouble reproducing the issue. To double check, you're using an external mouse with a real wheel? (As opposed to a laptop touchpad). Also, is your screen low or high DPI (if you open up devtools and print out window.devicePixelRatio, > 1.5 is considered high DPI). To help us repro locally, would you be able to grab a screen recording of the bug in action? Also, if you could capture and attach a trace using these instructions it might help: https://www.chromium.org/developers/how-tos/submitting-a-performance-bug. Thanks!
,
Sep 12
I have an external mouse, yes. Just to be sure it wasn't my mouse, I tried it from two different computers and mouses: - Logitech MX Master 2S on Surface Book 2 - Evoluent vertical mouse 4C on a HP ProBook. I created the trace by reproducing the bug once, but in the video I did it a few times. Entering window.devicePixelRatio in the console printed 1. For the trace and video, I'm using an external monitor in any case, and it's set as my only display in Windows' settings at 1920x1080 resolution, 100% scale.
,
Sep 13
I could reproduce the bug locally. Assigning it to myself to investigate more.
,
Sep 14
Oh, I think I misunderstood the bug, it's that the page scrolls rather than the list even though the mouse is over the list, right? In that case, that's intentional and is the latching behavior. There's a small timeout when using a mouse wheel during which we wont retarget the scroll.
,
Sep 14
With timer-based latching if all the GSUs in a sequence are getting ignored, we break the latching on direction change to force new hit testing. With this behavior, scrolling up latches to the page scroller since neither the list nor the page can scroll upward, but then when the scrolling direction changes to down we should break the current sequence immediately, and the next wheel should be in a new sequence and latch to the scroller. I think the issue is that sometimes the wheel event with phaseBegan gets coalesced to its previous wheel event with phaseEnded, in this case it is as if we did not break latching on direction change. |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by guillaum...@gmail.com
, Sep 11