Fire pointerup/down events for corresponding mouse events.

Fire pointerup/down events for corresponding mouse events.

Includes tests for pointerup/down event properties and for prevent
default behavior.

Also fixed a crack in eventSender that kept MouseEvent buttons unset.

BUG=476571, 541311
Committed: https://crrev.com/8911f4e9580ef8a1ed15cb87c7274184ac831d90
Cr-Commit-Position: refs/heads/master@{#356339}

[mustaq, 2015-10-08 20:41:48]

Patchset #3 (id:40001) has been deleted

[mustaq, 2015-10-08 20:47:21]

Patchset #3 (id:60001) has been deleted

[mustaq, 2015-10-20 17:59:21]

Patchset #2 (id:20001) has been deleted

[mustaq, 2015-10-20 18:01:36]

Patchset #2 (id:80001) has been deleted

[mustaq, 2015-10-20 18:02:20]

[email protected] changed reviewers:
+ [email protected]

[mustaq, 2015-10-20 18:02:21]

ptal

[mustaq, 2015-10-20 18:12:23]

Description was changed from

==========
Fire pointerup/down events for corresponding mouse events.

Also added tests for pointerup/down event properties, and for prevent
default behavior.

This CL follows the one on pointerenter/leave/over/out
(crrev.com/1379613002).

BUG=476571,541311
==========

to

==========
Fire pointerup/down events for corresponding mouse events.

Includes tests for pointerup/down event properties and for prevent
default behavior.

Also fixed a crack in eventSender that kept MouseEvent buttons unset.

BUG=476571,541311
==========

[Rick Byers, 2015-10-20 19:09:50]

Looks good, just one issue I can see.

https://codereview.chromium.org/1391393002/diff/100001/third_party/WebKit/Lay...
File
third_party/WebKit/LayoutTests/fast/events/pointerevents/mouse-pointer-event-properties.html
(right):

https://codereview.chromium.org/1391393002/diff/100001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/fast/events/pointerevents/mouse-pointer-event-properties.html:75:
shouldBeEqualToNumber("lastPointerEvent.pointerId", 0);
curious: does Edge still have this behavior of always using 0 for Mouse?  I know
that was removed from the spec.  But if they changed their impl to have more
random identifiers then we might want to consider that too (I doubt they did).

https://codereview.chromium.org/1391393002/diff/100001/third_party/WebKit/Lay...
File
third_party/WebKit/LayoutTests/fast/events/pointerevents/mouse-pointer-updown-events.html
(right):

https://codereview.chromium.org/1391393002/diff/100001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/fast/events/pointerevents/mouse-pointer-updown-events.html:11:
float: none;
curious why you need these rules.  If the console is getting in your way you can
use the lazy test output option to avoid actually updating the DOM until the
test is complete.

https://codereview.chromium.org/1391393002/diff/100001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/fast/events/pointerevents/mouse-pointer-updown-events.html:26:
var eventToPreventDefault = "";
Isn't this really redundant with your preventDefault test?

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

https://codereview.chromium.org/1391393002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/input/EventHandler.cpp:1264: bool
swallowMouseUpEvent = false;
I think there can be cases where blink doesn't directly see this mouseup (which
you probably need tests for).  Eg:
1. mousedown inside one frame, drag out to parent frame and mouseup there (your
state is per-frame, right?)
2. mousedown inside the window, drag out of the window and mouseup there.  This
will be a little trickier - we don't reliably get MouseLeave notifications from
chromium ATM (Lan is working on this).  Perhaps you just want to reset when you
see any mouse event that has no buttons down?

[mustaq, 2015-10-21 15:17:21]

ptal

https://codereview.chromium.org/1391393002/diff/100001/third_party/WebKit/Lay...
File
third_party/WebKit/LayoutTests/fast/events/pointerevents/mouse-pointer-event-properties.html
(right):

https://codereview.chromium.org/1391393002/diff/100001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/fast/events/pointerevents/mouse-pointer-event-properties.html:75:
shouldBeEqualToNumber("lastPointerEvent.pointerId", 0);
On 2015/10/20 19:09:50, Rick Byers wrote:
> curious: does Edge still have this behavior of always using 0 for Mouse?  I
know
> that was removed from the spec.  But if they changed their impl to have more
> random identifiers then we might want to consider that too (I doubt they did).

Edge uses id=1 for mouse.

I am tracking this though crbug.com/537319, also mentioned in PointerEvent.cpp.
Let me know if my suggestion in the bug makes sense.

https://codereview.chromium.org/1391393002/diff/100001/third_party/WebKit/Lay...
File
third_party/WebKit/LayoutTests/fast/events/pointerevents/mouse-pointer-updown-events.html
(right):

https://codereview.chromium.org/1391393002/diff/100001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/fast/events/pointerevents/mouse-pointer-updown-events.html:11:
float: none;
On 2015/10/20 19:09:50, Rick Byers wrote:
> curious why you need these rules.  If the console is getting in your way you
can
> use the lazy test output option to avoid actually updating the DOM until the
> test is complete.

I try to make the console divs sane to ease quick manual testing (through
file:// or jsbin etc.). Not a strong point though. I will remove it if you still
prefer minimal styling here.

https://codereview.chromium.org/1391393002/diff/100001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/fast/events/pointerevents/mouse-pointer-updown-events.html:26:
var eventToPreventDefault = "";
On 2015/10/20 19:09:50, Rick Byers wrote:
> Isn't this really redundant with your preventDefault test?

Done, left only the tests for bubbled events here.

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

https://codereview.chromium.org/1391393002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/input/EventHandler.cpp:1264: bool
swallowMouseUpEvent = false;
On 2015/10/20 19:09:50, Rick Byers wrote:
> I think there can be cases where blink doesn't directly see this mouseup
(which
> you probably need tests for).  Eg:
> 1. mousedown inside one frame, drag out to parent frame and mouseup there
(your
> state is per-frame, right?)
> 2. mousedown inside the window, drag out of the window and mouseup there. 
This
> will be a little trickier - we don't reliably get MouseLeave notifications
from
> chromium ATM (Lan is working on this).  Perhaps you just want to reset when
you
> see any mouse event that has no buttons down?

Yes, this is dependent on Lan's work. Filed crbug/545647 to track this, added a
TODO for now.

I think a reasonable fix would need some mousemove cleanup. Firing pointercancel
on mouse exit could be an intermediate fix but that would still need some
mousemove fix.

Relying on no-button mouseevents sounds scary to me, like our redundant
mousemove bugs.

[mustaq, 2015-10-22 16:39:58]

Patchset #4 (id:140001) has been deleted

[mustaq, 2015-10-22 16:42:52]

ptal

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

https://codereview.chromium.org/1391393002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/input/EventHandler.cpp:1264: bool
swallowMouseUpEvent = false;
On 2015/10/21 15:17:21, mustaq wrote:
> On 2015/10/20 19:09:50, Rick Byers wrote:
> > I think there can be cases where blink doesn't directly see this mouseup
> (which
> > you probably need tests for).  Eg:
> > 1. mousedown inside one frame, drag out to parent frame and mouseup there
> (your
> > state is per-frame, right?)
> > 2. mousedown inside the window, drag out of the window and mouseup there. 
> This
> > will be a little trickier - we don't reliably get MouseLeave notifications
> from
> > chromium ATM (Lan is working on this).  Perhaps you just want to reset when
> you
> > see any mouse event that has no buttons down?
> 
> Yes, this is dependent on Lan's work. Filed crbug/545647 to track this, added
a
> TODO for now.
> 
> I think a reasonable fix would need some mousemove cleanup. Firing
pointercancel
> on mouse exit could be an intermediate fix but that would still need some
> mousemove fix.
> 
> Relying on no-button mouseevents sounds scary to me, like our redundant
> mousemove bugs.

Here is a patch that resets the "prevent-ME" state upon seeing a no-button
native event as you suggested above.

[Rick Byers, 2015-10-22 21:31:51]

LGTM

https://codereview.chromium.org/1391393002/diff/100001/third_party/WebKit/Lay...
File
third_party/WebKit/LayoutTests/fast/events/pointerevents/mouse-pointer-event-properties.html
(right):

https://codereview.chromium.org/1391393002/diff/100001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/fast/events/pointerevents/mouse-pointer-event-properties.html:75:
shouldBeEqualToNumber("lastPointerEvent.pointerId", 0);
On 2015/10/21 15:17:21, mustaq wrote:
> On 2015/10/20 19:09:50, Rick Byers wrote:
> > curious: does Edge still have this behavior of always using 0 for Mouse?  I
> know
> > that was removed from the spec.  But if they changed their impl to have more
> > random identifiers then we might want to consider that too (I doubt they
did).
> 
> Edge uses id=1 for mouse.
> 
> I am tracking this though crbug.com/537319, also mentioned in
PointerEvent.cpp.
> Let me know if my suggestion in the bug makes sense.

Ok, added comments there - but let's not block this CL (doesn't really matter
for now).

https://codereview.chromium.org/1391393002/diff/100001/third_party/WebKit/Lay...
File
third_party/WebKit/LayoutTests/fast/events/pointerevents/mouse-pointer-updown-events.html
(right):

https://codereview.chromium.org/1391393002/diff/100001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/fast/events/pointerevents/mouse-pointer-updown-events.html:11:
float: none;
On 2015/10/21 15:17:21, mustaq wrote:
> On 2015/10/20 19:09:50, Rick Byers wrote:
> > curious why you need these rules.  If the console is getting in your way you
> can
> > use the lazy test output option to avoid actually updating the DOM until the
> > test is complete.
> 
> I try to make the console divs sane to ease quick manual testing (through
> file:// or jsbin etc.). Not a strong point though. I will remove it if you
still
> prefer minimal styling here.

Yeah that makes sense, just wondering who the heck is putting a float or
non-zero padding on the console.  js-test.js doesn't do that by default (it's
just a simple div in the pages I've seen with a couple minor css rules).

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

https://codereview.chromium.org/1391393002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/input/EventHandler.cpp:1264: bool
swallowMouseUpEvent = false;
On 2015/10/22 16:42:52, mustaq wrote:
> On 2015/10/21 15:17:21, mustaq wrote:
> > On 2015/10/20 19:09:50, Rick Byers wrote:
> > > I think there can be cases where blink doesn't directly see this mouseup
> > (which
> > > you probably need tests for).  Eg:
> > > 1. mousedown inside one frame, drag out to parent frame and mouseup there
> > (your
> > > state is per-frame, right?)
> > > 2. mousedown inside the window, drag out of the window and mouseup there. 
> > This
> > > will be a little trickier - we don't reliably get MouseLeave notifications
> > from
> > > chromium ATM (Lan is working on this).  Perhaps you just want to reset
when
> > you
> > > see any mouse event that has no buttons down?
> > 
> > Yes, this is dependent on Lan's work. Filed crbug/545647 to track this,
added
> a
> > TODO for now.
> > 
> > I think a reasonable fix would need some mousemove cleanup. Firing
> pointercancel
> > on mouse exit could be an intermediate fix but that would still need some
> > mousemove fix.
> > 
> > Relying on no-button mouseevents sounds scary to me, like our redundant
> > mousemove bugs.
> 
> Here is a patch that resets the "prevent-ME" state upon seeing a no-button
> native event as you suggested above.

I played with edge a bit here.  To match their behavior I think something like
this is necessary (even if we were getting reliable MouseLeave notifications). 
Note the difference between dragging (with the mouse down) out of a window and
back in, and dragging out, then lifting and moving back in.  The later
definitely cleared the "PREVENT MOUSE EVENT flag" even though no pointerup or
pointercancel was dispatched.  This is perhaps a bug in the spec, do you want to
file one and see what the Edge folks say?  I suspect they'll suggest adding
specific wording around clearing the flag on any event with button=0.

[mustaq, 2015-10-23 14:57:08]

Patchset #5 (id:170001) has been deleted

[mustaq, 2015-10-23 14:59:44]

https://codereview.chromium.org/1391393002/diff/100001/third_party/WebKit/Lay...
File
third_party/WebKit/LayoutTests/fast/events/pointerevents/mouse-pointer-updown-events.html
(right):

https://codereview.chromium.org/1391393002/diff/100001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/fast/events/pointerevents/mouse-pointer-updown-events.html:11:
float: none;
On 2015/10/22 21:31:51, Rick Byers wrote:
> On 2015/10/21 15:17:21, mustaq wrote:
> > On 2015/10/20 19:09:50, Rick Byers wrote:
> > > curious why you need these rules.  If the console is getting in your way
you
> > can
> > > use the lazy test output option to avoid actually updating the DOM until
the
> > > test is complete.
> > 
> > I try to make the console divs sane to ease quick manual testing (through
> > file:// or jsbin etc.). Not a strong point though. I will remove it if you
> still
> > prefer minimal styling here.
> 
> Yeah that makes sense, just wondering who the heck is putting a float or
> non-zero padding on the console.  js-test.js doesn't do that by default (it's
> just a simple div in the pages I've seen with a couple minor css rules).

The generic 'div' style I set above is the culprit. Didn't even notice it's a
copy of a hack I hadn't meant to submit originally. Fixed all copies, yikes!

[mustaq, 2015-10-23 14:59:50]

The CQ bit was checked by [email protected]

[mustaq, 2015-10-23 14:59:51]

The patchset sent to the CQ was uploaded after l-g-t-m from [email protected]
Link to the patchset: https://codereview.chromium.org/1391393002/#ps190001
(title: "Fixed test style for console div.")

[commit-bot: I haz the power, 2015-10-23 15:00:06]

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

[commit-bot: I haz the power, 2015-10-23 15:47:00]

The CQ bit was unchecked by [email protected]

[commit-bot: I haz the power, 2015-10-23 15:47:01]

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

[mustaq, 2015-10-23 19:27:18]

The CQ bit was checked by [email protected]

[mustaq, 2015-10-23 19:27:18]

The patchset sent to the CQ was uploaded after l-g-t-m from [email protected]
Link to the patchset: https://codereview.chromium.org/1391393002/#ps210001
(title: "Fixed mouse-click-event test bad click.")

[commit-bot: I haz the power, 2015-10-23 19:27:47]

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

[commit-bot: I haz the power, 2015-10-23 21:36:49]

The CQ bit was unchecked by [email protected]

[commit-bot: I haz the power, 2015-10-23 21:36:50]

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_...)

[mustaq, 2015-10-26 18:45:58]

The CQ bit was checked by [email protected]

[mustaq, 2015-10-26 18:45:58]

The patchset sent to the CQ was uploaded after l-g-t-m from [email protected]
Link to the patchset: https://codereview.chromium.org/1391393002/#ps230001
(title: "Fixed right-click context menu issues in test.")

[commit-bot: I haz the power, 2015-10-26 18:47:28]

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

[commit-bot: I haz the power, 2015-10-26 20:59:15]

The CQ bit was unchecked by [email protected]

[commit-bot: I haz the power, 2015-10-26 20:59:16]

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_...)

[mustaq, 2015-10-27 15:49:21]

Patchset #7 (id:230001) has been deleted

[mustaq, 2015-10-27 15:49:31]

Patchset #8 (id:270001) has been deleted

[mustaq, 2015-10-27 15:49:40]

Patchset #7 (id:250001) has been deleted

[mustaq, 2015-10-27 16:08:43]

The CQ bit was checked by [email protected]

[mustaq, 2015-10-27 16:08:43]

The patchset sent to the CQ was uploaded after l-g-t-m from [email protected]
Link to the patchset: https://codereview.chromium.org/1391393002/#ps290001
(title: "Skipped the failing test.")

[commit-bot: I haz the power, 2015-10-27 16:09:00]

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

[commit-bot: I haz the power, 2015-10-27 18:10:30]

Committed patchset #7 (id:290001)

[commit-bot: I haz the power, 2015-10-27 18:11:37]

Patchset 7 (id:??) landed as
https://crrev.com/8911f4e9580ef8a1ed15cb87c7274184ac831d90
Cr-Commit-Position: refs/heads/master@{#356339}