Suspecting wheel gestures. This is a good example of where we need to be testing the full input stack in our layout tests (or get better integration tests in place).

I think this is a high-dpi/low-dpi issue.

It works on my workstation.

Looks like if you disable threaded scrolling it works correctly when I simulate a high dpi device.

Appears to be related to compositor side hit testing.

It seems that the vertical scrollbar's member function ToScrollbarLayer returns a nullptr, so LayerTreeImpl thinks it is not a scrollbar layer. Trying to figure out why.

>It seems that the vertical scrollbar's member function ToScrollbarLayer returns a nullptr, so LayerTreeImpl thinks it is not a scrollbar layer. Trying to figure out why.

That's really weird. It could be a bug in hit testing, since we call LTHI::HandleMouseOverScrollbar with whatever layer is returned by hit testing. This is broken for quite some time now. Its broken in 51.0.2704.84 on Mac Retina. 

The scrollbar on calendar and gmail on high-DPI screen is a custom scrollbar, and in ScrollingCoordinator::scrollableAreaScrollbarLayerDidChange, we do not create a ScrollbarLayer when there is a custom scrollbar. So we end up with only a scrollbarGraphicsLayer which is just a GraphicsLayer and ToScrollbarLayer call returns nullptr.

After discussing with ajuma@, I'm going to add a main thread scrolling reason for custom scrollbars, since there is no way for the compositor to know if a layer is a custom scrollbar container layer.

That doesn't seem like a good idea, that means we'll start main thread scrolling on all google products (Gmail, Calendar, Docs, ...) because they all use custom scrollbar styles. We just recently started threaded scrolling in docs, it's a big improvement. Lets not regress that.

Or rather, do you mean only if we hover the scrollbar, but hovering the main content and scrolling would still threaded scroll? That does seem okay to fix this high priority regression, but long term we need to fix this so there's not a weird cliff hovering the scrollbar. :)

Hovering the main content should be scrolling on compositor thread as the gesture hits the content scrollable layer instead of the scrollbar layer, so yes you are right, this should not affect the most common case.

For hovering the scrollbar, all scrollbars (not only custom scrollbar) have always been forced to scroll on main thread, so I think it would not be a regression.

See https://cs.chromium.org/chromium/src/cc/input/main_thread_scrolling_reason.h, we already have a main thread scrolling reason "kScrollbarScrolling".

That's for when you're dragging the scrollbar, not hovering it and fling
scrolling the track pad. Flings over the scrollbar being janky is very
weird.

If that's true, we need to have low-priority goal to re-enable compositor scrolling for that. But we can land the change as a fast fix. Adding ajuma@ and bokan@ to this discussion.

Just to re-emphasize: it's already the case that for non-custom scrollbars, flings while hovering over the scrollbar are handled on the main thread. The suggestion in #7 is about treating custom scrollbars the same way.

The fundamental underlying issue is that in CompositedLayerMapping, scrollbars are not descendants of the scrollable content itself, so the compositor doesn't "know" that scrolling a scrollbar should be interpreted as a request to scroll the content. Doing any major re-architecting of CompositedLayerMapping doesn't seem like a good investment right now given that it's being deleted as part of SPv2.

IMO, all user input should be scrolled on the compositor, including scrollbars. Ages ago, I wrote up a CL that handled scrollbars on the compositor. It was before I knew anything and it was a hack so it never landed but it's possible.

I've filed  issue 622349  to track making scrollbar scrolls handle on the compositor (both dragging and wheeling). I agree we should wait until SPv2 is at least further along to avoid duplicating work. Is there a meta bug for SPv2 we could block on?

Issue 471333 is the SPv2 meta bug.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/599a0d9d885bae01856dc0c716bf851389fe3330

commit 599a0d9d885bae01856dc0c716bf851389fe3330
Author: sunxd <sunxd@chromium.org>
Date: Fri Jun 24 17:34:13 2016

cc: Make custom scrollbar scroll on main thread

The compositor hit testing needs to let the main thread deal with
scrolling on a scrollbar layer. However some webpages on high-DPI screen
have a custom scrollbar. The compositor cannot figure out if a layer is
a custom scrollbar as it is only a GraphicsLayer in blink.

This CL forces custom scrollbars scroll on main thread so that gestures
on scrollbars can be correctly processed.

BUG= 618183 
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Review-Url: https://codereview.chromium.org/2085853003
Cr-Commit-Position: refs/heads/master@{#401891}

[modify] https://crrev.com/599a0d9d885bae01856dc0c716bf851389fe3330/cc/input/main_thread_scrolling_reason.h
[modify] https://crrev.com/599a0d9d885bae01856dc0c716bf851389fe3330/third_party/WebKit/Source/core/page/scrolling/ScrollingCoordinator.cpp
[modify] https://crrev.com/599a0d9d885bae01856dc0c716bf851389fe3330/third_party/WebKit/Source/web/tests/ScrollingCoordinatorTest.cpp
[add] https://crrev.com/599a0d9d885bae01856dc0c716bf851389fe3330/third_party/WebKit/Source/web/tests/data/custom_scrollbar.html