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

Committed: https://crrev.com/4ab3ab417ec9ddaa3672219ea3dba4e8b35f1518
Cr-Commit-Position: refs/heads/master@{#393568}

[tdresser, 2016-04-22 20:35:10]

The CQ bit was checked by tdresser@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-04-22 20:35:56]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1907323003/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1907323003/1

[commit-bot: I haz the power, 2016-04-22 21:21:57]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-04-22 21:21:58]

Dry run: Try jobs failed on following builders:
  linux_chromium_chromeos_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[tdresser, 2016-04-29 14:44:59]

The CQ bit was checked by tdresser@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-04-29 14:45:12]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1907323003/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1907323003/20001

[tdresser, 2016-04-29 14:52:04]

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 caused problems for OOPIF/webview event targetting (and was
clearly wrong).

This patch sends cancel events correctly. 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. This patch provides this extra
state on demand, sending a touch press event through directly before
the touch cancel.

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

BUG=604454
TEST=TODO
==========

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. This patch provides this extra state on
demand, sending press events through directly before the
touch cancel.

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

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

[tdresser, 2016-04-29 14:52:15]

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

[tdresser, 2016-04-29 14:52:16]

Sadrul, does this seem reasonable?

[commit-bot: I haz the power, 2016-04-29 15:03:34]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-04-29 15:03:35]

Dry run: Try jobs failed on following builders:
  linux_chromium_chromeos_compile_dbg_ng on tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[tdresser, 2016-04-29 16:43:11]

The CQ bit was checked by tdresser@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-04-29 16:43:25]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1907323003/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1907323003/40001

[commit-bot: I haz the power, 2016-04-29 17:24:29]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-04-29 17:24:29]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[tdresser, 2016-04-29 18:04:53]

The CQ bit was checked by tdresser@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-04-29 18:05:08]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1907323003/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1907323003/60001

[commit-bot: I haz the power, 2016-04-29 19:13:01]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-04-29 19:13:02]

Dry run: This issue passed the CQ dry run.

[tdresser, 2016-05-02 13:20:30]

Ping.

[sadrul, 2016-05-02 14:10:13]

> This patch provides this extra state on
> demand, sending press events through directly before
> the touch cancel.

Can you clarify this from the CL description a little? When we do a transfer
from A to B, A currently does not get a touch-cancel. Also, for the next
touch-start, A does not receive a touch-start. This is the issue you are fixing
in this CL?

[tdresser, 2016-05-02 14:18:34]

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. This patch provides this extra state on
demand, sending press events through directly before the
touch cancel.

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

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

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 dispatch extra touch
press events, to get the gesture recognizer state for the source
window back in sync with the pointers that are down on it, and
then we dispatch cancel events to the source window. These
extra press events are ignored by the RenderWidgetHostViewAura,
so they don't reach web contents.

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
==========

[tdresser, 2016-05-02 14:19:50]

Thanks, that CL description was somewhat out of sync with the state of the code.

Is that clearer?

The problem we're solving is that, in the drag and drop case, we previously
never received a touch cancel event on the source window.

[tdresser, 2016-05-03 13:08:49]

Ping - this is a stable blocker, and we've already branched, so I'm trying to
get this in ASAP.

[sadrul, 2016-05-03 18:38:16]

https://codereview.chromium.org/1907323003/diff/60001/ui/events/gestures/gest...
File ui/events/gestures/gesture_recognizer.h (right):

https://codereview.chromium.org/1907323003/diff/60001/ui/events/gestures/gest...
ui/events/gestures/gesture_recognizer.h:74: virtual void
BeginTabDrag(GestureConsumer* current_consumer,
GR is a fairly low-level component; it shouldn't need to know to behave
differently for high-level concepts like tab-drag. I would go with
TransferEventsTo(current, new, should_cancel_current). The caller can decide
whether it wants the cancel events or not.

https://codereview.chromium.org/1907323003/diff/60001/ui/events/gestures/gest...
File ui/events/gestures/gesture_recognizer_impl.cc (right):

https://codereview.chromium.org/1907323003/diff/60001/ui/events/gestures/gest...
ui/events/gestures/gesture_recognizer_impl.cc:178:
helper->DispatchSyntheticTouchEvent(event.get());
We really shouldn't dispatch a second set of touch-presses when transferring the
gesture-state/sequence. RWHVA may know to deal with it, but there can be other
consumers, and we can't expect all of them to expect this. The GR may see an
invalid event-stream, as in it sees cancels without corresponding press, but
that should be OK?

[tdresser, 2016-05-03 18:56:42]

https://codereview.chromium.org/1907323003/diff/60001/ui/events/gestures/gest...
File ui/events/gestures/gesture_recognizer.h (right):

https://codereview.chromium.org/1907323003/diff/60001/ui/events/gestures/gest...
ui/events/gestures/gesture_recognizer.h:74: virtual void
BeginTabDrag(GestureConsumer* current_consumer,
On 2016/05/03 18:38:16, sadrul wrote:
> GR is a fairly low-level component; it shouldn't need to know to behave
> differently for high-level concepts like tab-drag. I would go with
> TransferEventsTo(current, new, should_cancel_current). The caller can decide
> whether it wants the cancel events or not.

That was my instinct initially too, but I changed my mind upon further
reflection.

I agree that this is bad, but I think it's bad because the behavior of drag and
drop and tab dragging is logically coupled tightly to this behavior. Pretending
the tight coupling doesn't exist by giving things a general name doesn't prevent
the tight coupling. The correct fix here requires decoupling the behavior of tab
drag and drag and drop from the gesture recognizer, but this would likely be
fairly difficult, of questionable value, and definitely not merge-able to M51.

I think it's important that it be clear that these are not general purpose
methods that you should call when you want to transfer an event stream, but very
specific methods with behavior tailored for specific use cases.

We really don't want additional consumers of these methods, and I think making
them extremely specific is a good approach.

The behaviors required for tab drag vs. drag and drop are pretty fundamentally
different, and I think being explicit about this is worth the layering
violation.

https://codereview.chromium.org/1907323003/diff/60001/ui/events/gestures/gest...
File ui/events/gestures/gesture_recognizer_impl.cc (right):

https://codereview.chromium.org/1907323003/diff/60001/ui/events/gestures/gest...
ui/events/gestures/gesture_recognizer_impl.cc:178:
helper->DispatchSyntheticTouchEvent(event.get());
On 2016/05/03 18:38:16, sadrul wrote:
> We really shouldn't dispatch a second set of touch-presses when transferring
the
> gesture-state/sequence. RWHVA may know to deal with it, but there can be other
> consumers, and we can't expect all of them to expect this. The GR may see an
> invalid event-stream, as in it sees cancels without corresponding press, but
> that should be OK?

That would mean we'd need to relax this:
https://code.google.com/p/chromium/codesearch#chromium/src/ui/events/gestures...

It's pretty nice to be able to ignore all touches that don't have a
corresponding press.

I could perhaps add a back-door to update the GR state, instead of dispatching
presses?

[sadrul, 2016-05-04 13:28:18]

https://codereview.chromium.org/1907323003/diff/60001/ui/events/gestures/gest...
File ui/events/gestures/gesture_recognizer.h (right):

https://codereview.chromium.org/1907323003/diff/60001/ui/events/gestures/gest...
ui/events/gestures/gesture_recognizer.h:74: virtual void
BeginTabDrag(GestureConsumer* current_consumer,
On 2016/05/03 18:56:42, tdresser wrote:
> On 2016/05/03 18:38:16, sadrul wrote:
> > GR is a fairly low-level component; it shouldn't need to know to behave
> > differently for high-level concepts like tab-drag. I would go with
> > TransferEventsTo(current, new, should_cancel_current). The caller can decide
> > whether it wants the cancel events or not.
> 
> That was my instinct initially too, but I changed my mind upon further
> reflection.
> 
> I agree that this is bad, but I think it's bad because the behavior of drag
and
> drop and tab dragging is logically coupled tightly to this behavior.
Pretending
> the tight coupling doesn't exist by giving things a general name doesn't
prevent
> the tight coupling. The correct fix here requires decoupling the behavior of
tab
> drag and drag and drop from the gesture recognizer, but this would likely be
> fairly difficult, of questionable value, and definitely not merge-able to M51.
> 
> I think it's important that it be clear that these are not general purpose
> methods that you should call when you want to transfer an event stream, but
very
> specific methods with behavior tailored for specific use cases.
> 
> We really don't want additional consumers of these methods, and I think making
> them extremely specific is a good approach.
> 
> The behaviors required for tab drag vs. drag and drop are pretty fundamentally
> different, and I think being explicit about this is worth the layering
> violation.

I think it's OK for the 'transfer sequence from A to B' to specify whether to
explicitly cancel the sequence in A or not, but I can also see that the caller
may not really know whether they want the cancels or not. So I am OK with what
you have here.

https://codereview.chromium.org/1907323003/diff/60001/ui/events/gestures/gest...
File ui/events/gestures/gesture_recognizer_impl.cc (right):

https://codereview.chromium.org/1907323003/diff/60001/ui/events/gestures/gest...
ui/events/gestures/gesture_recognizer_impl.cc:178:
helper->DispatchSyntheticTouchEvent(event.get());
On 2016/05/03 18:56:42, tdresser wrote:
> On 2016/05/03 18:38:16, sadrul wrote:
> > We really shouldn't dispatch a second set of touch-presses when transferring
> the
> > gesture-state/sequence. RWHVA may know to deal with it, but there can be
other
> > consumers, and we can't expect all of them to expect this. The GR may see an
> > invalid event-stream, as in it sees cancels without corresponding press, but
> > that should be OK?
> 
> That would mean we'd need to relax this:
>
https://code.google.com/p/chromium/codesearch#chromium/src/ui/events/gestures...
> 
> It's pretty nice to be able to ignore all touches that don't have a
> corresponding press.
> 
> I could perhaps add a back-door to update the GR state, instead of dispatching
> presses?

If not overly complicated, then yeah, I would go with that.

[tdresser, 2016-05-09 19:26:33]

The CQ bit was checked by tdresser@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-05-09 19:27:13]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1907323003/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1907323003/80001

[tdresser, 2016-05-09 19:28:32]

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 dispatch extra touch
press events, to get the gesture recognizer state for the source
window back in sync with the pointers that are down on it, and
then we dispatch cancel events to the source window. These
extra press events are ignored by the RenderWidgetHostViewAura,
so they don't reach web contents.

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
==========

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
==========

[commit-bot: I haz the power, 2016-05-09 21:32:55]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-09 21:32:57]

Dry run: This issue passed the CQ dry run.

[tdresser, 2016-05-10 12:12:48]

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

[tdresser, 2016-05-10 12:12:49]

+sky@ for:
chrome/browser/ui/views/tabs/tab_drag_controller.cc
ash/shelf/shelf_tooltip_manager_unittest.cc
ash/drag_drop/drag_drop_controller.cc

[sadrul, 2016-05-11 16:12:17]

lgtm

https://codereview.chromium.org/1907323003/diff/80001/ui/aura/window_event_di...
File ui/aura/window_event_dispatcher.cc (right):

https://codereview.chromium.org/1907323003/diff/80001/ui/aura/window_event_di...
ui/aura/window_event_dispatcher.cc:534: // in raw pixels, so we convert back to
raw pixels here.
Can you add a DCHECK() here that |event->type()| is always |ET_TOUCH_CANCELED|?
If that assumption changes, it'd be good to explicitly verify if we want to do
that.

[tdresser, 2016-05-11 16:32:31]

https://codereview.chromium.org/1907323003/diff/80001/ui/aura/window_event_di...
File ui/aura/window_event_dispatcher.cc (right):

https://codereview.chromium.org/1907323003/diff/80001/ui/aura/window_event_di...
ui/aura/window_event_dispatcher.cc:534: // in raw pixels, so we convert back to
raw pixels here.
On 2016/05/11 16:12:17, sadrul wrote:
> Can you add a DCHECK() here that |event->type()| is always
|ET_TOUCH_CANCELED|?
> If that assumption changes, it'd be good to explicitly verify if we want to do
> that.

Done.

[sky, 2016-05-12 15:43:34]

https://codereview.chromium.org/1907323003/diff/100001/ui/events/gestures/ges...
File ui/events/gestures/gesture_recognizer.h (right):

https://codereview.chromium.org/1907323003/diff/100001/ui/events/gestures/ges...
ui/events/gestures/gesture_recognizer.h:74: virtual void
BeginTabDrag(GestureConsumer* current_consumer,
This code sits lower in the stack than the tab dragging code. So using 'tab' in
the name feels wrong. Did you consider combining BeginDragAndDrop and
BeginTabDrag and making the combined function take a parameter indicating if the
events should be canceled?

[tdresser, 2016-05-12 16:27:51]

On 2016/05/12 15:43:34, sky wrote:
>
https://codereview.chromium.org/1907323003/diff/100001/ui/events/gestures/ges...
> File ui/events/gestures/gesture_recognizer.h (right):
> 
>
https://codereview.chromium.org/1907323003/diff/100001/ui/events/gestures/ges...
> ui/events/gestures/gesture_recognizer.h:74: virtual void
> BeginTabDrag(GestureConsumer* current_consumer,
> This code sits lower in the stack than the tab dragging code. So using 'tab'
in
> the name feels wrong. Did you consider combining BeginDragAndDrop and
> BeginTabDrag and making the combined function take a parameter indicating if
the
> events should be canceled?

See the discussion which concludes in
https://codereview.chromium.org/1907323003/#msg27.

[sky, 2016-05-12 17:54:32]

IMO that both Sadrul and myself pointed this out is an indication we
both expect the caller to be the one deciding, and that the lower
level shouldn't know about concepts in the higher level, just provide
the primitives.

On Thu, May 12, 2016 at 9:27 AM,  <tdresser@chromium.org> wrote:
> On 2016/05/12 15:43:34, sky wrote:
>>
>
https://codereview.chromium.org/1907323003/diff/100001/ui/events/gestures/ges...
>> File ui/events/gestures/gesture_recognizer.h (right):
>>
>>
>
https://codereview.chromium.org/1907323003/diff/100001/ui/events/gestures/ges...
>> ui/events/gestures/gesture_recognizer.h:74: virtual void
>> BeginTabDrag(GestureConsumer* current_consumer,
>> This code sits lower in the stack than the tab dragging code. So using
>> 'tab'
> in
>> the name feels wrong. Did you consider combining BeginDragAndDrop and
>> BeginTabDrag and making the combined function take a parameter indicating
>> if
> the
>> events should be canceled?
>
> See the discussion which concludes in
> https://codereview.chromium.org/1907323003/#msg27.
>
> https://codereview.chromium.org/1907323003/

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[tdresser, 2016-05-12 20:25:20]

Patchset #7 (id:120001) has been deleted

[tdresser, 2016-05-12 20:29:54]

Done.

[sky, 2016-05-12 21:55:53]

Thanks, LGTM - although I would be inclined to go with an enum as it's clearer
in calling code.

[tdresser, 2016-05-13 14:32:33]

Switched to enum.

[tdresser, 2016-05-13 14:32:39]

The CQ bit was checked by tdresser@chromium.org

[tdresser, 2016-05-13 14:32:39]

The patchset sent to the CQ was uploaded after l-g-t-m from sadrul@chromium.org,
sky@chromium.org
Link to the patchset: https://codereview.chromium.org/1907323003/#ps200001
(title: "More comment fixes.")

[commit-bot: I haz the power, 2016-05-13 14:32:52]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1907323003/200001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1907323003/200001

[commit-bot: I haz the power, 2016-05-13 14:56:18]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-13 14:56:20]

Try jobs failed on following builders:
  mac_chromium_gn_rel on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_gn_r...)

[tdresser, 2016-05-13 15:22:07]

The CQ bit was checked by tdresser@chromium.org

[tdresser, 2016-05-13 15:22:08]

The patchset sent to the CQ was uploaded after l-g-t-m from sadrul@chromium.org,
sky@chromium.org
Link to the patchset: https://codereview.chromium.org/1907323003/#ps220001
(title: "Fix Mac.")

[commit-bot: I haz the power, 2016-05-13 15:22:26]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1907323003/220001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1907323003/220001

[commit-bot: I haz the power, 2016-05-13 17:40:25]

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
==========

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
==========

[commit-bot: I haz the power, 2016-05-13 17:40:26]

Committed patchset #11 (id:220001)

[commit-bot: I haz the power, 2016-05-13 17:41:29]

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
==========

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

Committed: https://crrev.com/4ab3ab417ec9ddaa3672219ea3dba4e8b35f1518
Cr-Commit-Position: refs/heads/master@{#393568}
==========

[commit-bot: I haz the power, 2016-05-13 17:41:30]

Patchset 11 (id:??) landed as
https://crrev.com/4ab3ab417ec9ddaa3672219ea3dba4e8b35f1518
Cr-Commit-Position: refs/heads/master@{#393568}