wheel event handler makes it possible to "overscroll" a container
Reported by
tburn...@hubspot.com,
Feb 10 2017
|
||||||
Issue descriptionChrome Version : 56.0.2924.87 OS Version: OS X 10.12.3 URLs (if applicable) : http://s.codepen.io/TrevorBurnham/debug/dNgBKL/WPALYpwmxEEk Other browsers tested: Add OK or FAIL after other browsers where you have tested this issue: Safari 5: OK Firefox 4.x: OK IE 7/8/9: OK What steps will reproduce the problem? 1. Visit http://s.codepen.io/TrevorBurnham/debug/dNgBKL/WPALYpwmxEEk. Using the mousewheel, scroll to the top and bottom of the sidebar repeatedly. What is the expected result? The sidebar has a "wheel" event handler that should allow the mousewheel to cause scrolling within the sidebar while preventing it from affecting the scroll position of the body. What happens instead of that? First, there's an unexpected "flicker": You can see the body through the sidebar during scrolling. Second, in rare cases (see attached screenshots) the sidebar will be rendered in the wrong position: Even though it has `position: fixed` with `top: 0` and `bottom: 0`, it's not touching the top or bottom of the <body>. Its position according to the developer tools does not match up with its rendered position. Once any further scrolling occurs, it resumes being rendered in the correct position. For reasons I can't explain, this rare case is extremely hard to reproduce in the CodePen but quite easy to reproduce in a real-world app where I have a very similar setup. Perhaps the problem is more likely to occur when the DOM is more complex, or when the calculations in the wheel event handler are more intensive. Please provide any additional information below. Attach a screenshot if possible. UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
,
Feb 13 2017
,
Feb 14 2017
,
Feb 16 2017
,
Feb 21 2017
@tburnham : Unable to access the provided URL due to "debug view URL expired" page is displaying.Could you please provide us with a updated URL of the issue which would help us to triage the issue further. Thanks in Advance.
,
Feb 21 2017
Sorry, I didn't realize CodePen did that! Here's the Editor view of that Pen: http://codepen.io/TrevorBurnham/pen/dNgBKL I recommend switching to the Debug view from there, as the glitch seems to be more likely to occur when the rendered area is larger.
,
Feb 22 2017
Very interesting, this seems to only occur on high DPI (i.e. when we're compositing the fixed position element), yet the fixed position element also gets repainted on scroll (which is likely related to the flicker you see). Also I can consistently get the main frame to scroll if I start scrolling again after hitting the bottom of the sidebar without moving my mouse. As soon as the mouse moves it seems to correctly handle the events. Seems like we may have a targeting issue there. Peter, can you take a look? The incorrect visual update of the fixed position element could be related to issue 681951. Also, is this a regression in M-56 or just first noticed in 56?
,
Feb 2 2018
Peter, can you please take a look soon?
,
Dec 5
Ping |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by nyerramilli@chromium.org
, Feb 10 2017