PointerEvents for long-press: fix double firing & canceling MEs

PointerEvents for long-press: fix double firing & canceling MEs

This CL fixes two bugs related to PointerEvents and gesture long
presses:

A. We fire pointer events from touch events. Gesture long-press
handler was calling handleMousePressEvent, which caused firing
of additional pointer events for the same touch sequence. This
CL skips firing PEs from PlatformMouseEvents synthesized from
touch.

B. Canceling a pointerdown should suppress all following
MouseEvents, including those fires through touch-gestures. We
have fixed the GestureTap case before. This CL fixes the only
remaining ME case: MEs from gesture long-press.

BUG=627207, 606938
Committed: https://crrev.com/326934c3dd341e43ecaa2c05fbf7597f7c21764d
Cr-Commit-Position: refs/heads/master@{#406649}

[mustaq, 2016-07-12 21:24:33]

Description was changed from

==========
Fixed double-firing of PointerEvents for long-press.

BUG=627207
==========

to

==========
Fixed double-firing of PointerEvents for long-press.

We fire pointer events from touch events. For long-press, the call to
handleMousePressEvent(PlatformMouseEvent) was causing firing of additional
pointer events for the same touch sequence. This CL suppresses them.

BUG=627207
==========

[mustaq, 2016-07-12 21:25:00]

Description was changed from

==========
Fixed double-firing of PointerEvents for long-press.

We fire pointer events from touch events. For long-press, the call to
handleMousePressEvent(PlatformMouseEvent) was causing firing of additional
pointer events for the same touch sequence. This CL suppresses them.

BUG=627207
==========

to

==========
Fixed double-firing of PointerEvents for long-press.

We fire pointer events from touch events. For long-press,
the call to handleMousePressEvent(PlatformMouseEvent) was
causing firing of additional pointer events for the same
touch sequence. This CL suppresses them.

BUG=627207
==========

[mustaq, 2016-07-12 21:25:32]

mustaq@chromium.org changed reviewers:
+ dtapuska@chromium.org, rbyers@chromium.org

[mustaq, 2016-07-12 21:25:33]

ptal

[mustaq, 2016-07-12 21:25:35]

ptal

[mustaq, 2016-07-13 18:32:49]

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

[commit-bot: I haz the power, 2016-07-13 18:34:18]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-13 20:34:55]

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

[commit-bot: I haz the power, 2016-07-13 20:34:56]

Dry run: This issue passed the CQ dry run.

[Rick Byers, 2016-07-14 14:27:10]

https://codereview.chromium.org/2141993003/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/input/EventHandler.cpp (right):

https://codereview.chromium.org/2141993003/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/input/EventHandler.cpp:2398:
handleMousePressEvent(mouseEvent, true);
I think the real bug here related to the above FIXME and TODO comments.  

HandleGestureTap is careful to be explicit about what additional hit-tests need
to happen and call only in to the DOM mouse-event generation logic.  But here
we're calling the raw PlatformMouseEvent entrypoint.  That seems inconsistent
and wrong.  Couldn't we just follow the same pattern as HandleGestureTap (and
for the mousemove above) and invoke just the DOM event-generation logic rather
than re-using the entire low-level handleMousePressEvent code path?

That would then also open up the possibility of not firing the mousedown (I
think we probably shouldn't) and potentially avoiding the hit-test (though it
might be required for web compat).

Is that easy to do without a ton of code duplication / refactoring?  At a
minimum you shouldn't have to add any new "from touch" tracking, you've already
marked the PlatformMouseEvent as "FromTouch" above.

https://codereview.chromium.org/2141993003/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/input/EventHandler.h (right):

https://codereview.chromium.org/2141993003/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/input/EventHandler.h:149: WebInputEventResult
handleMousePressEvent(const PlatformMouseEvent&, const bool synthesizedFromTouch
= false);
PlatformMouseEvent already has a fromTouch() property, can you use that rather
than introduce a redundant-looking additional piece of state?

https://codereview.chromium.org/2141993003/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/input/EventHandler.h:287: int clickCount, const
PlatformMouseEvent&, const bool synthesizedFromTouch = false);
ditto

[mustaq, 2016-07-14 15:05:14]

https://codereview.chromium.org/2141993003/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/input/EventHandler.cpp (right):

https://codereview.chromium.org/2141993003/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/input/EventHandler.cpp:2398:
handleMousePressEvent(mouseEvent, true);
On 2016/07/14 14:27:10, Rick Byers wrote:
> I think the real bug here related to the above FIXME and TODO comments.  
> 
> HandleGestureTap is careful to be explicit about what additional hit-tests
need
> to happen and call only in to the DOM mouse-event generation logic.  But here
> we're calling the raw PlatformMouseEvent entrypoint.  That seems inconsistent
> and wrong.  Couldn't we just follow the same pattern as HandleGestureTap (and
> for the mousemove above) and invoke just the DOM event-generation logic rather
> than re-using the entire low-level handleMousePressEvent code path?
> 
> That would then also open up the possibility of not firing the mousedown (I
> think we probably shouldn't) and potentially avoiding the hit-test (though it
> might be required for web compat).
> 
> Is that easy to do without a ton of code duplication / refactoring?  At a
> minimum you shouldn't have to add any new "from touch" tracking, you've
already
> marked the PlatformMouseEvent as "FromTouch" above.

I tried to address the TODO but Edge sends mousedown/up before a contextmenu
event triggerred by a long-tap, so suppressing them looks breaking to me. I will
avoid doing it in this CL.

Also considered triggering only the DOM generation logic here but that would
bypass all the mouse-pressed related bookkeeping we are triggering here for
GestureLongPree, GestureLongTap & GestureTwoFingerTap. Do you it is safe to do
so?

I missed the FromTouch bit here, will use it if minimal DOM event generation
seems unsafe.

[Rick Byers, 2016-07-15 17:02:55]

On 2016/07/14 15:05:14, mustaq wrote:
>
https://codereview.chromium.org/2141993003/diff/1/third_party/WebKit/Source/c...
> File third_party/WebKit/Source/core/input/EventHandler.cpp (right):
> 
>
https://codereview.chromium.org/2141993003/diff/1/third_party/WebKit/Source/c...
> third_party/WebKit/Source/core/input/EventHandler.cpp:2398:
> handleMousePressEvent(mouseEvent, true);
> On 2016/07/14 14:27:10, Rick Byers wrote:
> > I think the real bug here related to the above FIXME and TODO comments.  
> > 
> > HandleGestureTap is careful to be explicit about what additional hit-tests
> need
> > to happen and call only in to the DOM mouse-event generation logic.  But
here
> > we're calling the raw PlatformMouseEvent entrypoint.  That seems
inconsistent
> > and wrong.  Couldn't we just follow the same pattern as HandleGestureTap
(and
> > for the mousemove above) and invoke just the DOM event-generation logic
rather
> > than re-using the entire low-level handleMousePressEvent code path?
> > 
> > That would then also open up the possibility of not firing the mousedown (I
> > think we probably shouldn't) and potentially avoiding the hit-test (though
it
> > might be required for web compat).
> > 
> > Is that easy to do without a ton of code duplication / refactoring?  At a
> > minimum you shouldn't have to add any new "from touch" tracking, you've
> already
> > marked the PlatformMouseEvent as "FromTouch" above.
> 
> I tried to address the TODO but Edge sends mousedown/up before a contextmenu
> event triggerred by a long-tap, so suppressing them looks breaking to me. I
will
> avoid doing it in this CL.

Yeah don't change the events sent as part of this patch.  We might want to do
that, and doing the refactoring I suggest would be a pre-requisite for that.

> Also considered triggering only the DOM generation logic here but that would
> bypass all the mouse-pressed related bookkeeping we are triggering here for
> GestureLongPree, GestureLongTap & GestureTwoFingerTap. Do you it is safe to do
> so?

What I did for GestureTap was to factor out the pieces we want and invoke them
explicitly.  What logic in particular do you need?  Is it perhaps just the same
as tap: EventHandler::handleMouseFocus and EventHandlerhandleMousePressEvent?

Also don't you have another existing PE-related bug here because you're ignoring
m_suppressMouseEventsFromGestures?  If a page calls preventDefault on the
pointerdown for a long press (or two finger tap) then we presumably should not
be sending any mouse events but SHOULD still dispatch the contextmenu event.

> I missed the FromTouch bit here, will use it if minimal DOM event generation
> seems unsafe.

[mustaq, 2016-07-15 22:12:49]

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

[commit-bot: I haz the power, 2016-07-15 22:13:16]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-15 23:35:11]

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

[commit-bot: I haz the power, 2016-07-15 23:35:12]

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

[mustaq, 2016-07-18 19:40:05]

Description was changed from

==========
Fixed double-firing of PointerEvents for long-press.

We fire pointer events from touch events. For long-press,
the call to handleMousePressEvent(PlatformMouseEvent) was
causing firing of additional pointer events for the same
touch sequence. This CL suppresses them.

BUG=627207
==========

to

==========
PointerEvents for long-press: fix double firing & canceling MEs

This CL fixes two bugs related to PointerEvents and gesture long
presses:

A. We fire pointer events from touch events. Gesture long-press
handler was calling handleMousePressEvent, which caused firing
of additional pointer events for the same touch sequence. This
CL replaces the call to handleMousePressEvent with a minimal
DOM event firing code to fix the double PE problem.

B. Canceling a pointerdown should suppress all following
MouseEvents, including those fires through touch-gestures. We
have fixed the GestureTap case before. This CL fixes the only
remaining ME case: MEs from gesture long-press.

BUG=627207,606938
==========

[mustaq, 2016-07-18 20:50:16]

https://codereview.chromium.org/2141993003/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/input/EventHandler.h (right):

https://codereview.chromium.org/2141993003/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/input/EventHandler.h:149: WebInputEventResult
handleMousePressEvent(const PlatformMouseEvent&, const bool synthesizedFromTouch
= false);
On 2016/07/14 14:27:10, Rick Byers wrote:
> PlatformMouseEvent already has a fromTouch() property, can you use that rather
> than introduce a redundant-looking additional piece of state?

Done.

https://codereview.chromium.org/2141993003/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/input/EventHandler.h:287: int clickCount, const
PlatformMouseEvent&, const bool synthesizedFromTouch = false);
On 2016/07/14 14:27:10, Rick Byers wrote:
> ditto

Done.

[mustaq, 2016-07-18 20:51:59]

> Also don't you have another existing PE-related bug here because you're
ignoring
> m_suppressMouseEventsFromGestures?  If a page calls preventDefault on the
> pointerdown for a long press (or two finger tap) then we presumably should not
> be sending any mouse events but SHOULD still dispatch the contextmenu event.

Done. I was planning to keep that separate but after flattening the DOM event
firing,
that fix looks trivial. Thanks.

[dtapuska, 2016-07-18 21:16:32]

https://codereview.chromium.org/2141993003/diff/80001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/fast/events/pointerevents/touch-pointer-long-press.html
(right):

https://codereview.chromium.org/2141993003/diff/80001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/fast/events/pointerevents/touch-pointer-long-press.html:62:
<body onload="run()">
is there a reason why this can't follow the 
test("ABC", function(test) {
  test.done();
});

code style that wpl typically follow? instead of an onload handler?

https://codereview.chromium.org/2141993003/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/input/GestureManager.cpp (right):

https://codereview.chromium.org/2141993003/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/input/GestureManager.cpp:315:
MouseEventWithHitTestResults mev(mouseEvent, targetedEvent.hitTestResult());
Is it safe to reuse the hit test result here? The other code in EventHandler
doesn't. What if the DOM mutates do to the mouse move? What about targeting
scrollbars on the two finger tap?

[mustaq, 2016-07-19 15:50:27]

ptal.

https://codereview.chromium.org/2141993003/diff/80001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/fast/events/pointerevents/touch-pointer-long-press.html
(right):

https://codereview.chromium.org/2141993003/diff/80001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/fast/events/pointerevents/touch-pointer-long-press.html:62:
<body onload="run()">
On 2016/07/18 21:16:31, dtapuska wrote:
> is there a reason why this can't follow the 
> test("ABC", function(test) {
>   test.done();
> });
> 
> code style that wpl typically follow? instead of an onload handler?

Good catch. Don't recall why I originally did it for the chorded
button test. Fixed both.

https://codereview.chromium.org/2141993003/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/input/GestureManager.cpp (right):

https://codereview.chromium.org/2141993003/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/input/GestureManager.cpp:315:
MouseEventWithHitTestResults mev(mouseEvent, targetedEvent.hitTestResult());
On 2016/07/18 21:16:31, dtapuska wrote:
> Is it safe to reuse the hit test result here? The other code in EventHandler
> doesn't. What if the DOM mutates do to the mouse move?

Brought back the hittest, got distracted by the fixme comment.

> What about targeting scrollbars on the two finger tap?

I followed Rick's suggestion here which makes more sense to me: keeping only
the minimal effects of mouse for gestures. Do you think we should call
passMousePressEventToScrollbar() for all affected gestures (long-press,
long-tap & two-finger tap)?

[mustaq, 2016-07-19 15:52:32]

https://codereview.chromium.org/2141993003/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/input/GestureManager.cpp (right):

https://codereview.chromium.org/2141993003/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/input/GestureManager.cpp:315:
MouseEventWithHitTestResults mev(mouseEvent, targetedEvent.hitTestResult());
On 2016/07/19 15:50:27, mustaq wrote:
> On 2016/07/18 21:16:31, dtapuska wrote:
> > Is it safe to reuse the hit test result here? The other code in EventHandler
> > doesn't. What if the DOM mutates do to the mouse move?
> 
> Brought back the hittest, got distracted by the fixme comment.
> 
> > What about targeting scrollbars on the two finger tap?
> 
> I followed Rick's suggestion here which makes more sense to me: keeping only
> the minimal effects of mouse for gestures. Do you think we should call
> passMousePressEventToScrollbar() for all affected gestures (long-press,
> long-tap & two-finger tap)?

Note that we don't passMousePressEventToScrollbar() on GestureTap.

[mustaq, 2016-07-19 19:41:36]

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

[commit-bot: I haz the power, 2016-07-19 19:42:06]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-19 20:57:31]

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

[commit-bot: I haz the power, 2016-07-19 20:57:32]

Dry run: This issue passed the CQ dry run.

[mustaq, 2016-07-20 14:36:18]

Description was changed from

==========
PointerEvents for long-press: fix double firing & canceling MEs

This CL fixes two bugs related to PointerEvents and gesture long
presses:

A. We fire pointer events from touch events. Gesture long-press
handler was calling handleMousePressEvent, which caused firing
of additional pointer events for the same touch sequence. This
CL replaces the call to handleMousePressEvent with a minimal
DOM event firing code to fix the double PE problem.

B. Canceling a pointerdown should suppress all following
MouseEvents, including those fires through touch-gestures. We
have fixed the GestureTap case before. This CL fixes the only
remaining ME case: MEs from gesture long-press.

BUG=627207,606938
==========

to

==========
PointerEvents for long-press: fix double firing & canceling MEs

This CL fixes two bugs related to PointerEvents and gesture long
presses:

A. We fire pointer events from touch events. Gesture long-press
handler was calling handleMousePressEvent, which caused firing
of additional pointer events for the same touch sequence. This
CL replaces the call to handleMousePressEvent from
EventHandler::sendContextMenuEventForGesture with a minimal DOM
event firing code to fix the double PE problem.

Since sendContextMenuEventForGesture is used in handlers for
GestureLongPress, GestureLongTap & GestureTwoFingerTap events,
the fix also affects internal bookkeeping around context menus
for GestureLongTap & GestureTwoFingerTap.

B. Canceling a pointerdown should suppress all following
MouseEvents, including those fires through touch-gestures. We
have fixed the GestureTap case before. This CL fixes the only
remaining ME case: MEs from gesture long-press.

BUG=627207,606938
==========

[mustaq, 2016-07-20 15:54:41]

https://codereview.chromium.org/2141993003/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/input/GestureManager.cpp (right):

https://codereview.chromium.org/2141993003/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/input/GestureManager.cpp:315:
MouseEventWithHitTestResults mev(mouseEvent, targetedEvent.hitTestResult());
On 2016/07/19 15:52:32, mustaq wrote:
> On 2016/07/19 15:50:27, mustaq wrote:
> > On 2016/07/18 21:16:31, dtapuska wrote:
> > > Is it safe to reuse the hit test result here? The other code in
EventHandler
> > > doesn't. What if the DOM mutates do to the mouse move?
> > 
> > Brought back the hittest, got distracted by the fixme comment.
> > 
> > > What about targeting scrollbars on the two finger tap?
> > 
> > I followed Rick's suggestion here which makes more sense to me: keeping only
> > the minimal effects of mouse for gestures. Do you think we should call
> > passMousePressEventToScrollbar() for all affected gestures (long-press,
> > long-tap & two-finger tap)?
> 
> Note that we don't passMousePressEventToScrollbar() on GestureTap.

Bad news: the cherry-picking of DOM events is causing a regression in CrOS:
long-press menu doesn't appear until touch-release.

I will go back to a minimal fix as in Patch1 (except that I will use the
"FromTouch" value in the PlatformMouseEvent instead of a bool param), to have
the fix landed before the hackatahon next week.

[mustaq, 2016-07-20 16:19:50]

Description was changed from

==========
PointerEvents for long-press: fix double firing & canceling MEs

This CL fixes two bugs related to PointerEvents and gesture long
presses:

A. We fire pointer events from touch events. Gesture long-press
handler was calling handleMousePressEvent, which caused firing
of additional pointer events for the same touch sequence. This
CL replaces the call to handleMousePressEvent from
EventHandler::sendContextMenuEventForGesture with a minimal DOM
event firing code to fix the double PE problem.

Since sendContextMenuEventForGesture is used in handlers for
GestureLongPress, GestureLongTap & GestureTwoFingerTap events,
the fix also affects internal bookkeeping around context menus
for GestureLongTap & GestureTwoFingerTap.

B. Canceling a pointerdown should suppress all following
MouseEvents, including those fires through touch-gestures. We
have fixed the GestureTap case before. This CL fixes the only
remaining ME case: MEs from gesture long-press.

BUG=627207,606938
==========

to

==========
PointerEvents for long-press: fix double firing & canceling MEs

This CL fixes two bugs related to PointerEvents and gesture long
presses:

A. We fire pointer events from touch events. Gesture long-press
handler was calling handleMousePressEvent, which caused firing
of additional pointer events for the same touch sequence. This
CL skips firing PEs from PlatformMouseEvents synthesized from
touch.

B. Canceling a pointerdown should suppress all following
MouseEvents, including those fires through touch-gestures. We
have fixed the GestureTap case before. This CL fixes the only
remaining ME case: MEs from gesture long-press.

BUG=627207,606938
==========

[mustaq, 2016-07-20 16:20:54]

ptal, removed all cherry-picking to maintain existing behavior.

[dtapuska, 2016-07-20 16:26:08]

lgtm % nits

https://codereview.chromium.org/2141993003/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/input/EventHandler.cpp (right):

https://codereview.chromium.org/2141993003/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/input/EventHandler.cpp:871:
InputDeviceCapabilities* sourceCapabilities = mouseEvent.getSyntheticEventType()
== PlatformMouseEvent::FromTouch
Is this "git cl format" doing the formatting changes? I imagine it isn't. I
personally prefer we don't make formatting changes that the tool doesn't do.

https://codereview.chromium.org/2141993003/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/input/EventHandler.cpp:1497: WebInputEventResult
EventHandler::updatePointerTargetAndDispatchEvents(
ditto

https://codereview.chromium.org/2141993003/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/input/EventHandler.cpp:1506: if
(mouseEvent.getSyntheticEventType() == PlatformMouseEvent::FromTouch) {
braces not needed

[mustaq, 2016-07-20 16:36:44]

https://codereview.chromium.org/2141993003/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/input/EventHandler.cpp (right):

https://codereview.chromium.org/2141993003/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/input/EventHandler.cpp:871:
InputDeviceCapabilities* sourceCapabilities = mouseEvent.getSyntheticEventType()
== PlatformMouseEvent::FromTouch
On 2016/07/20 16:26:08, dtapuska wrote:
> Is this "git cl format" doing the formatting changes? I imagine it isn't. I
> personally prefer we don't make formatting changes that the tool doesn't do.

Done.

https://codereview.chromium.org/2141993003/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/input/EventHandler.cpp:1497: WebInputEventResult
EventHandler::updatePointerTargetAndDispatchEvents(
On 2016/07/20 16:26:08, dtapuska wrote:
> ditto

Done.

https://codereview.chromium.org/2141993003/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/input/EventHandler.cpp:1506: if
(mouseEvent.getSyntheticEventType() == PlatformMouseEvent::FromTouch) {
On 2016/07/20 16:26:08, dtapuska wrote:
> braces not needed

Done.

[mustaq, 2016-07-20 16:38:07]

mustaq@chromium.org changed reviewers:
+ bokan@chromium.org

[mustaq, 2016-07-20 16:38:08]

bokan@chromium.org: Need approval in Source/core.

[mustaq, 2016-07-20 16:38:24]

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

[bokan, 2016-07-20 16:38:45]

rs-lgtm

[commit-bot: I haz the power, 2016-07-20 16:39:01]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[mustaq, 2016-07-20 18:03:12]

The CQ bit was unchecked by mustaq@chromium.org

[mustaq, 2016-07-20 18:03:24]

The CQ bit was checked by mustaq@chromium.org

[mustaq, 2016-07-20 18:03:25]

The patchset sent to the CQ was uploaded after l-g-t-m from
dtapuska@chromium.org
Link to the patchset: https://codereview.chromium.org/2141993003/#ps140001
(title: "Fixed formats.")

[commit-bot: I haz the power, 2016-07-20 18:03:47]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-20 20:17:15]

Description was changed from

==========
PointerEvents for long-press: fix double firing & canceling MEs

This CL fixes two bugs related to PointerEvents and gesture long
presses:

A. We fire pointer events from touch events. Gesture long-press
handler was calling handleMousePressEvent, which caused firing
of additional pointer events for the same touch sequence. This
CL skips firing PEs from PlatformMouseEvents synthesized from
touch.

B. Canceling a pointerdown should suppress all following
MouseEvents, including those fires through touch-gestures. We
have fixed the GestureTap case before. This CL fixes the only
remaining ME case: MEs from gesture long-press.

BUG=627207,606938
==========

to

==========
PointerEvents for long-press: fix double firing & canceling MEs

This CL fixes two bugs related to PointerEvents and gesture long
presses:

A. We fire pointer events from touch events. Gesture long-press
handler was calling handleMousePressEvent, which caused firing
of additional pointer events for the same touch sequence. This
CL skips firing PEs from PlatformMouseEvents synthesized from
touch.

B. Canceling a pointerdown should suppress all following
MouseEvents, including those fires through touch-gestures. We
have fixed the GestureTap case before. This CL fixes the only
remaining ME case: MEs from gesture long-press.

BUG=627207,606938
==========

[commit-bot: I haz the power, 2016-07-20 20:17:17]

Committed patchset #8 (id:140001)

[commit-bot: I haz the power, 2016-07-20 20:19:14]

Description was changed from

==========
PointerEvents for long-press: fix double firing & canceling MEs

This CL fixes two bugs related to PointerEvents and gesture long
presses:

A. We fire pointer events from touch events. Gesture long-press
handler was calling handleMousePressEvent, which caused firing
of additional pointer events for the same touch sequence. This
CL skips firing PEs from PlatformMouseEvents synthesized from
touch.

B. Canceling a pointerdown should suppress all following
MouseEvents, including those fires through touch-gestures. We
have fixed the GestureTap case before. This CL fixes the only
remaining ME case: MEs from gesture long-press.

BUG=627207,606938
==========

to

==========
PointerEvents for long-press: fix double firing & canceling MEs

This CL fixes two bugs related to PointerEvents and gesture long
presses:

A. We fire pointer events from touch events. Gesture long-press
handler was calling handleMousePressEvent, which caused firing
of additional pointer events for the same touch sequence. This
CL skips firing PEs from PlatformMouseEvents synthesized from
touch.

B. Canceling a pointerdown should suppress all following
MouseEvents, including those fires through touch-gestures. We
have fixed the GestureTap case before. This CL fixes the only
remaining ME case: MEs from gesture long-press.

BUG=627207,606938

Committed: https://crrev.com/326934c3dd341e43ecaa2c05fbf7597f7c21764d
Cr-Commit-Position: refs/heads/master@{#406649}
==========

[commit-bot: I haz the power, 2016-07-20 20:19:16]

Patchset 8 (id:??) landed as
https://crrev.com/326934c3dd341e43ecaa2c05fbf7597f7c21764d
Cr-Commit-Position: refs/heads/master@{#406649}