Failure to composite scroller due to pointer-events:none can break scroll-chaining |
|
Issue descriptionChrome Version : 72.0.3610.2 OS Version: URLs (if applicable) : https://output.jsbin.com/nelosuh/1/quiet What steps will reproduce the problem? 1. Scroll blue scroller all the way to bottom 2. Try scrolling down again from the now fully-scrolled blue scroller What is the expected result? The red scroller should scroll What happens instead of that? Nothing scrolls The issue here is that the blue scroller gets composited but its parent is not due to pointer-events: none. Because of that, when we scroll on the compositor thread, the scroll chain doesn't know about the red scroller and we skip it. This happens because the scroller is technically not "visible to hit testing" so we assume we don't need to composite it at: https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/paint/paint_layer_scrollable_area.cc?l=2117&rcl=5814800fa70a7a7a7975c9943cdf0c310873321c However, we should really check that it doesn't have a scrolling descendant before we prevent compositing.
,
Nov 28
(continuing from https://bugs.chromium.org/p/chromium/issues/detail?id=837007#c10) Oh nice was halfway through writing up the other issue. I'm not sure it's exactly as simple as you described being solely about pointer-events, because when I have previously changed the test case (https://output.jsbin.com/rutoceb/quiet) '.panels' element to have `overflow:hidden` then the bug disappears, even while still having pointer-events set the same on its parent and grandparent element. Also, I've struggled with setting up my chrome flags in the past, but thanks for the tip.
,
Dec 4
bokan@chromium.org is it your understanding that if you load up and inspect https://output.jsbin.com/rutoceb/quiet and alter `.panels` to have `overflow:hidden`, that in itself will cause blink to re-evaluate the code you reference (https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/paint/paint_layer_scrollable_area.cc?l=2117&rcl=5814800fa70a7a7a7975c9943cdf0c310873321c), essentially making it so the ancestor scroller will be "visible for hit testing" and the composite it???
,
Dec 5
There's two scrolling paths in Chrome (indeed, all browsers): a fast (composited) and a slow one. Adding styles like overflow:hidden can cause your scroller to go from one to the other. The bug here appears in the fast path but not the slow one. I don't know for sure (I haven't taken another deep dive) but my guess is that overflow: hidden forces Chrome to use the slow path (not immediately clear why but the reasons can be quite complicated) for your scroller where the bug isn't present. |
|
►
Sign in to add a comment |
|
Comment 1 by bokan@chromium.org
, Nov 28