Removed main-thread one dimensional scrolling paths.

third_party/WebKit/Source/core/input/EventHandler.h

Index: third_party/WebKit/Source/core/input/EventHandler.h
diff --git a/third_party/WebKit/Source/core/input/EventHandler.h b/third_party/WebKit/Source/core/input/EventHandler.h
index 348e59f2a888dff6f3bd0e673c56493fd41d17d7..de8394f686e155e6e077f97e68695e985b62a2b6 100644
--- a/third_party/WebKit/Source/core/input/EventHandler.h
+++ b/third_party/WebKit/Source/core/input/EventHandler.h
@@ -135,8 +135,8 @@ public:
 
     IntPoint dragDataTransferLocationForTesting();
 
-    // Attempts to scroll the DOM tree. If that fails, scrolls the view.
-    // If the view can't be scrolled either, recursively bubble to the parent frame.
+    // Performs a logical scroll that bubbles, crossing frames, starting from
+    // the given node or a reasonable default (focus/last clicked).
     bool bubblingScroll(ScrollDirection, ScrollGranularity, Node* startingNode = nullptr);
 
     WebInputEventResult handleMouseMoveEvent(const PlatformMouseEvent&);
@@ -265,17 +265,29 @@ private:
 
     ScrollableArea* associatedScrollableArea(const PaintLayer*) const;
 
-    // Scrolls the elements of the DOM tree. Returns true if a node was scrolled.
-    // False if we reached the root and couldn't scroll anything.
-    // direction - The direction to scroll in. If this is a logical direction, it will be
-    //             converted to the physical direction based on a node's writing mode.
+    // Performs a bubbling scroll, within a *single* frame, starting from a

[tdresser, 2016/02/29 14:53:43]

I'd prefer if we used the terms "bubble" and "chain" to refer to event bubbling,
and scroll chaining respectively. It's confusing that we use the word bubble to
refer both to scrolling and to event dispatch.

I don't know if it's worth renaming "bubblingScroll", but it would be nice if we
could use the word "chain" in comments.

[bokan, 2016/03/01 05:56:24]

I've updated the comments. I'd like to remove bubblingScroll and replace it with
logicalScroll anyway so I'll do that in a followup.

+    // given node and optionally stopping on a given node. Does *not* attempt
+    // to scroll the layout view.
     // granularity - The units that the  scroll delta parameter is in.
-    // startNode - The node to start bubbling the scroll from. If a node can't scroll,
-    //             the scroll bubbles up to the containing block.
-    // stopNode - On input, if provided and non-null, the node at which we should stop bubbling on input.
-    //            On output, if provided and a node was scrolled stopNode will point to that node.
-    // delta - The delta to scroll by, in the units of the granularity parameter. (e.g. pixels, lines, pages, etc.)
-    ScrollResultOneDimensional scroll(ScrollDirection, ScrollGranularity, Node* startNode = nullptr, Node** stopNode = nullptr, float delta = 1.0f);
+    // delta - The delta to scroll by, in the units of the granularity param
+    //         (e.g. pixels, lines, pages, etc.). These are in a physical
+    //         direction. i.e. Positive is down and right.
+    // startNode - The node to start bubbling the scroll from.
+    // stopNode - On input, if provided and non-null, the node at which we
+    //            should stop bubbling. On output, if provided and a node was
+    //            scrolled, stopNode will point to that node.
+    ScrollResult physicalScroll(ScrollGranularity, const FloatSize& delta, Node* startNode, Node** stopNode = nullptr);
+
+    // Performs a bubbling logical scroll, within a *single* frame, starting
+    // from either a provided starting node or a default based on focus/clicked.

[tdresser, 2016/02/29 14:53:43]

"based on focus/clicked"

Can this be a bit more precise? "based on the focused or most recently clicked
Node"? or something along those lines?

[bokan, 2016/03/01 05:56:24]

Done.

+    // Returns true if the scroll was consumed.
+    // direction - The logical direction to scroll in. This will be converted to
+    //             a physical direction for each LayoutBox we try to scroll
+    //             based on that box's writing mode.

[skobes, 2016/02/29 18:52:47]

Is this behavior covered by any spec?  It seems a little surprising that
chaining might scroll an ancestor in the opposite physical direction.

[bokan, 2016/03/01 05:56:24]

I'm not sure about a spec, but this is just describing long-existing behaviour.
Basically, if you press the space bar the scroll is in the "block-forward"
direction. This means that depending on which element ends up consuming the
scroll and what its writing direction is, we might scroll in different
directions. This is only used for directionless scrolls like that.

+    // granularity - The size of the scroll.
+    // startNode - Optional. If provided, start bubbling from the given node.
+    //             If not, use the current focus or last clicked node.
+    bool logicalScroll(ScrollDirection, ScrollGranularity, Node* startNode = nullptr);
 
     void resetOverscroll(bool didScrollX, bool didScrollY);
     void handleOverscroll(const ScrollResult&, const FloatPoint& position = FloatPoint(), const FloatSize& velocity = FloatSize());