Pointer events are disabled in invisible scrollbar area after scrolling |
||||||||
Issue descriptionChrome Version : 52.0.2743.116 OS Version: OS X 10.11.6 URLs (if applicable) : https://go-review.googlesource.com/c/28816/1/src/bytes/buffer.go?polygerrit=1 Other browsers tested: Add OK or FAIL after other browsers where you have tested this issue: Safari 9.1.2 (11601.7.7): FAIL Firefox 48: PASS What steps will reproduce the problem? See attached video to better understand the issue: https://www.youtube.com/watch?v=9O85ybJytak The URL in the video is https://go-review.googlesource.com/c/28816/1/src/bytes/buffer.go?polygerrit=1 Content underneath the invisible scroll bar area is interactive UNTIL the user scrolls, after which it can’t be interacted with. UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36
,
Sep 12 2016
Issue gerrit:4525 has been merged into this issue.
,
Sep 12 2016
s/invisible scrollbar/overlay scrollbar/ This is possibly an input bug or a layout bug.
,
Sep 15 2016
pinkerton@ does someone on the Mac team have some cycles to fix this? I presume something in https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/scroll/ScrollbarThemeMac.mm seems wrong for horizontal scrollers.
,
Sep 19 2016
+shrike, tapted Trent has been doing a lot with scrolling lately, he might have some insight. If he doesn't have cycles, shrike can find someone.
,
Sep 20 2016
Haven't started toying with scrollbars for the content area yet. Scroll *areas*, yes, but the way scroll*bars* are currently plumbed through for the content area is super complicated, so I'm essentially starting from scratch with something simpler. I think in this case there's a number of divs with overflow-x: auto that are creating scrollable regions. But the scrollbar logic is tuned mainly for root viewport scrolling (e.g. there is no elasticity for scrollable divs). With the divs, it's getting confused. E.g. I can't repro this on crbug.com. On PolyGerrit, I can't repro exactly -- it's flaky -- but I've managed to get things into a state where the overlay scroller never disappears. That may indicate the problem (i.e. if it disappears visually but is still "there" that could explain why pointer events are not routed properly). I don't know whether the overlay scrollbar code really has an owner at all - it's probably something we inherited from WebKit and have been too scared to touch. ccameron may know a bit more history... But I certainly haven't wrapped tried to wrap my head around it, and if we can adapt the much simpler approach we're using for overlay scrollbars in UI I may never have to. But that would still be many, many months away.
,
Sep 20 2016
,
Sep 20 2017
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 23 2017
Unable to reproduce on ToT. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by kochi@chromium.org
, Sep 9 2016