Drag and drop cleans up touch sequences from the source window.

Drag and drop cleans up touch sequences from the source window.

Previously we would just leave the source window thinking it had
a pointer touching it the whole time, and then when a new pointer
came down, we'd ignore that event. This behavior is required for
tab drag, but not for drag and drop.

This caused problems for OOPIF/webview event targetting.

This patch sends cancel events correctly in the drag and drop
case. This is a bit tricky, because during drag and drop, we move
a gesture recognizer from the source window to the destination
window, leaving the source window with no gesture recognition
state. To deal with this, we send press events to the gesture
recognizer without sending them to the associated window, to get
the gesture recognizer state for the source window back in sync
with the pointers that are active on it, and then we dispatch
cancel events to the source window.

Ideally we'd just clone the GR state and then send the cancel
events, but cloning the GR state would be painful.

The tab drag case is left untouched - when dragging a tab,
the source window continues to think that a pointer is down
throughout the tab drag, until the finger is raised.

BUG=604454
TEST=GestureProviderAuraTest.IgnoresExtraPressEvents, GestureRecognizerTest.PressDoesNotCrash

Review-Url: https://codereview.chromium.org/1907323003
Cr-Commit-Position: refs/heads/master@{#393568}
(cherry picked from commit 4ab3ab417ec9ddaa3672219ea3dba4e8b35f1518)

Committed: https://chromium.googlesource.com/chromium/src/+/bbe2f039113871b17b7ce6a3ab243eb9432d4720

[tdresser, 2016-05-18 18:45:27]

Description was changed from

==========
Drag and drop cleans up touch sequences from the source window.

Previously we would just leave the source window thinking it had
a pointer touching it the whole time, and then when a new pointer
came down, we'd ignore that event. This behavior is required for
tab drag, but not for drag and drop.

This caused problems for OOPIF/webview event targetting.

This patch sends cancel events correctly in the drag and drop
case. This is a bit tricky, because during drag and drop, we move
a gesture recognizer from the source window to the destination
window, leaving the source window with no gesture recognition
state. To deal with this, we send press events to the gesture
recognizer without sending them to the associated window, to get
the gesture recognizer state for the source window back in sync
with the pointers that are active on it, and then we dispatch
cancel events to the source window.

Ideally we'd just clone the GR state and then send the cancel
events, but cloning the GR state would be painful.

The tab drag case is left untouched - when dragging a tab,
the source window continues to think that a pointer is down
throughout the tab drag, until the finger is raised.

BUG=604454
TEST=GestureProviderAuraTest.IgnoresExtraPressEvents,
GestureRecognizerTest.PressDoesNotCrash

Review-Url: https://codereview.chromium.org/1907323003
Cr-Commit-Position: refs/heads/master@{#393568}
(cherry picked from commit 4ab3ab417ec9ddaa3672219ea3dba4e8b35f1518)
==========

to

==========
Drag and drop cleans up touch sequences from the source window.

Previously we would just leave the source window thinking it had
a pointer touching it the whole time, and then when a new pointer
came down, we'd ignore that event. This behavior is required for
tab drag, but not for drag and drop.

This caused problems for OOPIF/webview event targetting.

This patch sends cancel events correctly in the drag and drop
case. This is a bit tricky, because during drag and drop, we move
a gesture recognizer from the source window to the destination
window, leaving the source window with no gesture recognition
state. To deal with this, we send press events to the gesture
recognizer without sending them to the associated window, to get
the gesture recognizer state for the source window back in sync
with the pointers that are active on it, and then we dispatch
cancel events to the source window.

Ideally we'd just clone the GR state and then send the cancel
events, but cloning the GR state would be painful.

The tab drag case is left untouched - when dragging a tab,
the source window continues to think that a pointer is down
throughout the tab drag, until the finger is raised.

BUG=604454
TEST=GestureProviderAuraTest.IgnoresExtraPressEvents,
GestureRecognizerTest.PressDoesNotCrash

Review-Url: https://codereview.chromium.org/1907323003
Cr-Commit-Position: refs/heads/master@{#393568}
(cherry picked from commit 4ab3ab417ec9ddaa3672219ea3dba4e8b35f1518)

Committed:
https://chromium.googlesource.com/chromium/src/+/bbe2f039113871b17b7ce6a3ab24...
==========

[tdresser, 2016-05-18 18:45:28]

Committed patchset #1 (id:1) manually as
bbe2f039113871b17b7ce6a3ab243eb9432d4720.