GitLab

The logic for handling 2-finger swipes should be:
1. If a 2-finger swipe can scroll the content (or iframe), it should do so.
2. If the 2-finger swipe can cause history navigation, it should do so.
3. The 2-finger swipe should rubber-band the content view.

(2) is handled by the embedder, and (1 & 3) by the renderer. Right now, the
renderer is passed an IPC, and it tries to do (1), and then it tries to do (3).
I've added a new IPC so that there are flags that prevent the renderer from
performing (3) under specific circumstances.

There was an existing mechanism to determine whether the renderer should try
(3), but it was fragile, incorrectly used, and insufficient for newer features
in chrome - the user can cancel a history swipe without cancelling the gesture,
at which point rubber-banding should be possible again. I've simplified and
fixed the logic inside ScrollElasticityController.mm to reflect the desired
behavior.

I modified the IPC InputMsg_HandleInputEvent to include 2 additional bools:
can_rubberband_left and can_rubberband_right. Blink will attempt to consume the
event to scroll the content view, and will only attempt to rubberband if bools
allow it too.

This is part 1 of a two-part change. It only includes the IPC change. The
changes to ScrollElasticityController will land after I've updated Chromium to
use the new API.

BUG=321437

Review URL: https://codereview.chromium.org/197213011

git-svn-id: svn://svn.chromium.org/blink/trunk@170102 bbb929c8-8fbe-4397-9dbb-9b2b20218538