Thanks, I'll take a look

There's a few things going on here.

The page blocks on external imports being loaded before doing layout/style so we haven't built the layout tree when the scrolls come in so that's why the DCHECK is firing here. This would normally be ok since the LayoutView should be available on the documentNode but we're actually trying to scroll the HTML element which doesn't yet have a LayoutObject. I think the reason we try to scroll HTML rather than #document is because of some ViewportScrollCallback special-cases where we fall back to documentElement (since it can have an applyScroll). We're missing a short-circuit in the case documentElement doesn't have a LayoutObject. I'll add that.

More worryingly, it seems that we never get a GestureScrollBegin here. CC sees a ScrollBegin but Blink doesn't but the following ScrollUpdate and ScrollEnds are forwarded to Blink. This seems like a problem to me. Dave/Tim, is there a reason for this or is this a routing bug?

PS, to repro you need to actually scroll while the page is loading. Once the scrollbar shows up scrolling works just fine.

Additionally, in Blink, when we get a ScrollUpdate/End and don't yet have a target we go and do a hit test. That seems error prone to me. Now that we have wheel gestures, is there a reason we shouldn't limit hit testing to ScrollBegin?

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

commit 41c5c138b099891457c2e0cb965b8f24dacc403e
Author: bokan <bokan@chromium.org>
Date: Wed Oct 12 01:09:51 2016

Make sure we don't try scrolling a node without a LayoutObject

Early out of Blink's scrolling code if there's no LayoutObject to
scroll.

BUG= 653327 

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

[modify] https://crrev.com/41c5c138b099891457c2e0cb965b8f24dacc403e/third_party/WebKit/Source/core/input/ScrollManager.cpp
[modify] https://crrev.com/41c5c138b099891457c2e0cb965b8f24dacc403e/third_party/WebKit/Source/web/tests/WebFrameTest.cpp
[add] https://crrev.com/41c5c138b099891457c2e0cb965b8f24dacc403e/third_party/WebKit/Source/web/tests/data/display-none.html

And I'm wondering why no one's responding to my questions :) +Dave/Tim, see comments 2-4.

It is possible looking at the code that the gesture scroll begin is handled by the compositor but then when it goes to handled the gesture scroll update ScrollAnimated returns it can't handle it. https://cs.chromium.org/chromium/src/ui/events/blink/input_handler_proxy.cc?q=Input_handler_proxy.cc&sq=package:chromium&l=675

And then it could fall into the did_not_handle which will end up sending it to the main thread.

I agree a GSU without a GSB is odd since the GSB should do the hit test.

Ok, I've filed a new bug under Hotlist-CodeHealth ( issue 655143 ) to make sure GSUs are always framed by a GSB and GSE and to make sure we hit test only on GSB. The DCHECK in this bug should be fixed by the patch above.

Thanks for the quick fix :)