Cleanup viewport scrolling for future scroll customization work.

Cleanup viewport scrolling for future scroll customization work.

Viewport scrolling previously returned a struct of information about
what scrolled. This complicated scroll customization. This patch makes
|Viewport::ScrollBy| return a single |Vector2dF|, as well as performing
some other cleanup that will simplify scroll customization.

BUG=505851
TEST=LayerTreeHostImplTest, WebContentsViewAuraTest.VerticalOverscroll
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Committed: https://crrev.com/3e773d7aeba1eb0077a7907d0f5ff2e72e1c6753
Cr-Commit-Position: refs/heads/master@{#337694}

[tdresser, 2015-07-06 15:22:44]

tdresser@chromium.org changed reviewers:
+ vollick@chromium.org

[tdresser, 2015-07-06 15:22:44]

Let me know if there's a better reviewer for this change.

Scroll customization relies on a strict interface for communication during
scroll chaining. The Viewport previously returned a bunch of information that
didn't line up well with this interface.

This change aligns viewport scrolling with the interface used by scroll
customization, along with a few other minor changes to simplify the
implementation of scroll customization.

The WIP native only scroll customization patch is here:
https://codereview.chromium.org/1215183004.

https://codereview.chromium.org/1223713004/diff/20001/content/renderer/gpu/re...
File content/renderer/gpu/render_widget_compositor.cc (right):

https://codereview.chromium.org/1223713004/diff/20001/content/renderer/gpu/re...
content/renderer/gpu/render_widget_compositor.cc:446:
settings.report_overscroll_only_for_scrollable_axes = false;
This value was previously set incorrectly for aura. We rely on overscroll
information for gesture navigation, which needs to take place regardless of
whether or not an axis is scrollable.

Without this change WebContentsViewAuraTest.VerticalOverscroll fails.

[Ian Vollick, 2015-07-06 15:33:16]

https://codereview.chromium.org/1223713004/diff/20001/cc/trees/layer_tree_hos...
File cc/trees/layer_tree_host_impl.cc (right):

https://codereview.chromium.org/1223713004/diff/20001/cc/trees/layer_tree_hos...
cc/trees/layer_tree_host_impl.cc:2621: if (is_direct_manipulation)
It looks like there's a real behavior change here. Is that true? If so, this
should have some new test coverage.

[tdresser, 2015-07-06 15:39:29]

https://codereview.chromium.org/1223713004/diff/20001/cc/trees/layer_tree_hos...
File cc/trees/layer_tree_host_impl.cc (right):

https://codereview.chromium.org/1223713004/diff/20001/cc/trees/layer_tree_hos...
cc/trees/layer_tree_host_impl.cc:2621: if (is_direct_manipulation)
On 2015/07/06 15:33:16, vollick wrote:
> It looks like there's a real behavior change here. Is that true? If so, this
> should have some new test coverage.

Nope, no behavior change. With scroll customization, we're trying not to tie
things to the kind of input device (i.e. mousewheel or touch). Instead, we're
trying to base behavior on properties of the input device. In this case, the
property of the input device that we care about is whether or not the user is
interacting directly with the screen (which currently will only be through
touch) or not (which currently will only be through trackpad). Throughout this
change, is_direct_manipulation == !is_wheel_scroll, and we invert the relevant
conditions where needed.

With scroll customization, we'll be passing this information in the ScrollIntent
object, as described here:
https://docs.google.com/document/d/1VnvAqeWFG9JFZfgG5evBqrLGDZYRE5w6G5jEDORek....

[Ian Vollick, 2015-07-06 17:11:12]

On 2015/07/06 15:39:29, tdresser wrote:
>
https://codereview.chromium.org/1223713004/diff/20001/cc/trees/layer_tree_hos...
> File cc/trees/layer_tree_host_impl.cc (right):
> 
>
https://codereview.chromium.org/1223713004/diff/20001/cc/trees/layer_tree_hos...
> cc/trees/layer_tree_host_impl.cc:2621: if (is_direct_manipulation)
> On 2015/07/06 15:33:16, vollick wrote:
> > It looks like there's a real behavior change here. Is that true? If so, this
> > should have some new test coverage.
> 
> Nope, no behavior change. With scroll customization, we're trying not to tie
> things to the kind of input device (i.e. mousewheel or touch). Instead, we're
> trying to base behavior on properties of the input device. In this case, the
> property of the input device that we care about is whether or not the user is
> interacting directly with the screen (which currently will only be through
> touch) or not (which currently will only be through trackpad). Throughout this
> change, is_direct_manipulation == !is_wheel_scroll, and we invert the relevant
> conditions where needed.
> 
> With scroll customization, we'll be passing this information in the
ScrollIntent
> object, as described here:
>
https://docs.google.com/document/d/1VnvAqeWFG9JFZfgG5evBqrLGDZYRE5w6G5jEDORek....

Thank you for the explanation. In that case, lgtm.

[tdresser, 2015-07-06 17:22:44]

tdresser@chromium.org changed reviewers:
+ enne@chromium.org

[tdresser, 2015-07-06 17:22:45]

enne@, can you take a look at content/renderer/gpu/render_widget_compositor.cc?

[enne (OOO), 2015-07-07 20:42:50]

lgtm

[tdresser, 2015-07-07 20:44:39]

The CQ bit was checked by tdresser@chromium.org

[commit-bot: I haz the power, 2015-07-07 20:44:47]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1223713004/20001

[commit-bot: I haz the power, 2015-07-07 22:16:21]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-07-07 22:17:14]

Patchset 2 (id:??) landed as
https://crrev.com/3e773d7aeba1eb0077a7907d0f5ff2e72e1c6753
Cr-Commit-Position: refs/heads/master@{#337694}

[tdresser, 2015-07-09 17:18:17]

A revert of this CL (patchset #2 id:20001) has been created in
https://codereview.chromium.org/1227823005/ by tdresser@chromium.org.

The reason for reverting is: See crbug.com/508509.

We need to fix this case before relanding..