Merged FrameView and LayoutBox scrolling in EventHandler.

third_party/WebKit/Source/core/layout/LayoutView.cpp

Index: third_party/WebKit/Source/core/layout/LayoutView.cpp
diff --git a/third_party/WebKit/Source/core/layout/LayoutView.cpp b/third_party/WebKit/Source/core/layout/LayoutView.cpp
index 5da123b695f693d7e53dedbd6546c97f8156820b..470e3c8de77c0f87f0c5d90fddbb21909adb5e6c 100644
--- a/third_party/WebKit/Source/core/layout/LayoutView.cpp
+++ b/third_party/WebKit/Source/core/layout/LayoutView.cpp
@@ -1022,4 +1022,12 @@ bool LayoutView::allowsOverflowClip() const
     return document().settings() && document().settings()->rootLayerScrolls();
 }
 
+ScrollResult LayoutView::scroll(ScrollGranularity granularity, const FloatSize& delta)
+{

[szager1, 2016/03/02 19:14:35]

I think you should probably add this at the top of this method (skobes@ should
confirm):

if (document().settings() && document().settings()->rootLayerScrolls())
    return LayoutBlockFlow::scroll(granularity, delta);

[bokan, 2016/03/02 20:37:13]

Thanks for the heads up. This shouldn't change the flow from what we do today -
we're just calling applyScrollDelta from here rather than EventHandler, but I
can believe it's wrong today. I'll let skobes@ comment.

[skobes, 2016/03/02 23:26:30]

LocalFrame::applyScrollDelta calls through FrameView::scrollableArea() so it
will do the right thing in root layer scrolling mode.

That said, perhaps this overload can go away with scroll customization, given
that we already have logic in Element::nativeApplyScroll to call
LocalFrame::applyScrollDelta?

[bokan, 2016/03/02 23:33:19]

I think you're right. Right now, I'm just trying to remove some of the crazy
duplication we've got going on in EventHandler. Though I like the symmetry of
calling code not having to make a distinction between LayoutBoxes.

+    if (!frameView())
+        return ScrollResult();
+
+    return frame()->applyScrollDelta(granularity, delta, false);
+}
+
 } // namespace blink