Separate mouse transition events from pointerevent

Separate mouse transition events from pointerevent

This CL will separate sending mouse transition events
from pointer events (with type=mouse) transitions as they might belong
to different node anyway. This allows us more separation
of mouse event and pointer events.

BUG=587955
Committed: https://crrev.com/fd312312165253f96bd75c19716444805fadf087
Cr-Commit-Position: refs/heads/master@{#383787}

[Navid Zolghadr, 2016-03-16 16:39:28]

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

[Navid Zolghadr, 2016-03-16 16:39:28]

This is a tentative change to address the issue of the difference between mouse
transition events and pointerevents with type=mouse.

Note that one of the tests (i.e. mouse-pointer-event-properties-expected.txt) is
quite hard to fix with this method of sending the events. But I wanted to get
your first thoughts on this before putting more time into fixing that test.
However, the rest of the tests give you an idea of the sequence of transition
events after this change. Please take a look and let me know what you think and
whether this is okay or not.

[mustaq, 2016-03-16 19:06:37]

Here are my quick comments: since we will have to fire mousedown etc after
pointerdown etc, the same order should be maintained for transition events.

I will get back to it next week after returning from my vacation.

https://codereview.chromium.org/1809603003/diff/1/third_party/WebKit/LayoutTe...
File
third_party/WebKit/LayoutTests/virtual/pointerevent/fast/events/pointerevents/mouse-pointer-transition-events-expected.txt
(right):

https://codereview.chromium.org/1809603003/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/virtual/pointerevent/fast/events/pointerevents/mouse-pointer-transition-events-expected.txt:6:
green received mouseover, at phase=target
While I agree we may have to group mouse transition events together like this,
we will want them /after/ the pointer event group.

Do Edge & FF group mouse events together?

[Navid Zolghadr, 2016-03-16 19:39:33]

https://codereview.chromium.org/1809603003/diff/1/third_party/WebKit/LayoutTe...
File
third_party/WebKit/LayoutTests/virtual/pointerevent/fast/events/pointerevents/mouse-pointer-transition-events-expected.txt
(right):

https://codereview.chromium.org/1809603003/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/virtual/pointerevent/fast/events/pointerevents/mouse-pointer-transition-events-expected.txt:6:
green received mouseover, at phase=target
On 2016/03/16 19:06:37, mustaq wrote:
> While I agree we may have to group mouse transition events together like this,
> we will want them /after/ the pointer event group.
> 
> Do Edge & FF group mouse events together?

Edge doesn't do the grouping and FF does and does send the pointer event group
before mouse event group. I will change this CL to send pointer event group
first instead of this.

[Navid Zolghadr, 2016-03-18 16:10:38]

ptal.

I applied the comment about ordering of mouse transition events and pointer
transition events and add the test that cover all the edge cases that were not
covered previously in the capture test case.

[mustaq, 2016-03-22 15:28:43]

https://codereview.chromium.org/1809603003/diff/40001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/virtual/pointerevent/fast/events/pointerevents/mouse-pointer-capture-transition-events-expected.txt
(right):

https://codereview.chromium.org/1809603003/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/virtual/pointerevent/fast/events/pointerevents/mouse-pointer-capture-transition-events-expected.txt:30:
green received pointermove
The enter/leave and over/out pairing in-between the test cases is also
important. Perhaps get rid of |loggingEnabled| completely.

https://codereview.chromium.org/1809603003/diff/40001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/virtual/pointerevent/fast/events/pointerevents/mouse-pointer-capture-transition-events.html
(right):

https://codereview.chromium.org/1809603003/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/virtual/pointerevent/fast/events/pointerevents/mouse-pointer-capture-transition-events.html:48:
document.addEventListener("lostpointercapture", function(event) {
We want to make sure |document| doesn't receive redundant events, so adding
document event-listeners has some value here even though we won't see these
events in the output. Why not listen for /all/ event-types here?

https://codereview.chromium.org/1809603003/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/virtual/pointerevent/fast/events/pointerevents/mouse-pointer-capture-transition-events.html:95:
eventSender.mouseUp(1);
Please include the implicit-release-triggered-events in the log.

https://codereview.chromium.org/1809603003/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/virtual/pointerevent/fast/events/pointerevents/mouse-pointer-capture-transition-events.html:98:
eventSender.leapForward(500);
Why do you need these 3 lines (down, up, leapForward)?

https://codereview.chromium.org/1809603003/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/input/PointerEventManager.cpp (right):

https://codereview.chromium.org/1809603003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/input/PointerEventManager.cpp:106: // Sends node
transition events (pointer|mouse)(out|leave|over|enter) to the corresponding
targets
Nuke this line, we have this in the header.

https://codereview.chromium.org/1809603003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/input/PointerEventManager.cpp:359:
m_preventMouseEventForPointerTypeMouse = false;
Resetting m_preventMouseEventForPointerTypeMouse twice in the same function
looks a bit hacky to me. Please try to consolidate them. The idea is simple: if
buttons==0, mouse-blocking is gone. The transition events are never blocked.

https://codereview.chromium.org/1809603003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/input/PointerEventManager.cpp:363:
lastNodeUnderMouse, mouseEvent, true, true);
I guess this is okay to pass the PassRefPtr lastNodeUnderMouse as a parameter
here since you are using it only once. If I am wrong here, please follow OilPan
team's guidance for the body of the first sendNodeTransitionEvents() above (in a
past CL IIRC). Otherwise, simplify the sendNodeTransitionEvents() body like
this.

https://codereview.chromium.org/1809603003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/input/PointerEventManager.cpp:405: void
PointerEventManager::prepareForFiringPointerEvent(
Please consider a more specific name here. Also add a description in the header
file.

https://codereview.chromium.org/1809603003/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/input/PointerEventManager.h (right):

https://codereview.chromium.org/1809603003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/input/PointerEventManager.h:45: // Sends node
transition events (pointer|mouse)(out|leave|over|enter) to the corresponding
targets
Name and describe the bool parameter in the comment here.

[Navid Zolghadr, 2016-03-22 18:00:24]

ptal.
I applied the comments and fix the test output as well as adding some extra
tests for cover more cases.

https://codereview.chromium.org/1809603003/diff/40001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/virtual/pointerevent/fast/events/pointerevents/mouse-pointer-capture-transition-events-expected.txt
(right):

https://codereview.chromium.org/1809603003/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/virtual/pointerevent/fast/events/pointerevents/mouse-pointer-capture-transition-events-expected.txt:30:
green received pointermove
On 2016/03/22 15:28:43, mustaq wrote:
> The enter/leave and over/out pairing in-between the test cases is also
> important. Perhaps get rid of |loggingEnabled| completely.

Sure. I will get rid of it.

https://codereview.chromium.org/1809603003/diff/40001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/virtual/pointerevent/fast/events/pointerevents/mouse-pointer-capture-transition-events.html
(right):

https://codereview.chromium.org/1809603003/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/virtual/pointerevent/fast/events/pointerevents/mouse-pointer-capture-transition-events.html:48:
document.addEventListener("lostpointercapture", function(event) {
On 2016/03/22 15:28:43, mustaq wrote:
> We want to make sure |document| doesn't receive redundant events, so adding
> document event-listeners has some value here even though we won't see these
> events in the output. Why not listen for /all/ event-types here?

Actually, as I copied this test from the other test I forgot to remove this
block altogether. Document element listeners will have the same effect of grey
div here in this test. Meaning that whenever grey gets leave/enter events
documents will also get it as the parent of grey div. I will get rid of document
listeners and just keep grey listeners to make it clear.

https://codereview.chromium.org/1809603003/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/virtual/pointerevent/fast/events/pointerevents/mouse-pointer-capture-transition-events.html:95:
eventSender.mouseUp(1);
On 2016/03/22 15:28:43, mustaq wrote:
> Please include the implicit-release-triggered-events in the log.

I will log all the events so this case is covered here too. But the some
implicit capturing scenarios were also tested in mouse-pointer-capture test.

https://codereview.chromium.org/1809603003/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/virtual/pointerevent/fast/events/pointerevents/mouse-pointer-capture-transition-events.html:98:
eventSender.leapForward(500);
On 2016/03/22 15:28:43, mustaq wrote:
> Why do you need these 3 lines (down, up, leapForward)?

I got it from my other test. IIRC without them Windows bot was failing having
some of the mousedown event suppressed! The problem was with selection and that
is why I didn't investigated any further for now.

https://codereview.chromium.org/1809603003/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/input/PointerEventManager.cpp (right):

https://codereview.chromium.org/1809603003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/input/PointerEventManager.cpp:106: // Sends node
transition events (pointer|mouse)(out|leave|over|enter) to the corresponding
targets
On 2016/03/22 15:28:43, mustaq wrote:
> Nuke this line, we have this in the header.

Done.

https://codereview.chromium.org/1809603003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/input/PointerEventManager.cpp:359:
m_preventMouseEventForPointerTypeMouse = false;
On 2016/03/22 15:28:43, mustaq wrote:
> Resetting m_preventMouseEventForPointerTypeMouse twice in the same function
> looks a bit hacky to me. Please try to consolidate them. The idea is simple:
if
> buttons==0, mouse-blocking is gone. The transition events are never blocked.

Following our discussion offline, this is still needed to handle the release
mouse outside of the page. I will add the comment explaining this here.

https://codereview.chromium.org/1809603003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/input/PointerEventManager.cpp:363:
lastNodeUnderMouse, mouseEvent, true, true);
On 2016/03/22 15:28:43, mustaq wrote:
> I guess this is okay to pass the PassRefPtr lastNodeUnderMouse as a parameter
> here since you are using it only once. If I am wrong here, please follow
OilPan
> team's guidance for the body of the first sendNodeTransitionEvents() above (in
a
> past CL IIRC). Otherwise, simplify the sendNodeTransitionEvents() body like
> this.

I believe you are right. I remember I was told that when it is only being
forwarded to another function it is okay to pass PassRefPtr. I will simplify
that function as well.

https://codereview.chromium.org/1809603003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/input/PointerEventManager.cpp:405: void
PointerEventManager::prepareForFiringPointerEvent(
On 2016/03/22 15:28:43, mustaq wrote:
> Please consider a more specific name here. Also add a description in the
header
> file.

I used processCaptureAndPositionOfPointerEvent. Is it more clear?

https://codereview.chromium.org/1809603003/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/input/PointerEventManager.h (right):

https://codereview.chromium.org/1809603003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/input/PointerEventManager.h:45: // Sends node
transition events (pointer|mouse)(out|leave|over|enter) to the corresponding
targets
On 2016/03/22 15:28:43, mustaq wrote:
> Name and describe the bool parameter in the comment here.

Done.

[mustaq, 2016-03-23 18:49:07]

LGTM, the transition events look perfect now. A couple of nits around
readability...

https://codereview.chromium.org/1809603003/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/input/PointerEventManager.cpp (right):

https://codereview.chromium.org/1809603003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/input/PointerEventManager.cpp:405: void
PointerEventManager::prepareForFiringPointerEvent(
On 2016/03/22 18:00:24, Navid Zolghadr wrote:
> On 2016/03/22 15:28:43, mustaq wrote:
> > Please consider a more specific name here. Also add a description in the
> header
> > file.
> 
> I used processCaptureAndPositionOfPointerEvent. Is it more clear?

Yes, thanks. Is |updateCaptureAndPosition| better? Your call.

https://codereview.chromium.org/1809603003/diff/60001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/virtual/pointerevent/fast/events/pointerevents/mouse-pointer-capture-transition-events-expected.txt
(right):

https://codereview.chromium.org/1809603003/diff/60001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/virtual/pointerevent/fast/events/pointerevents/mouse-pointer-capture-transition-events-expected.txt:6:
==== 'none' is capturing and then 'blue' will capture with border cross ====
I read "...will capture-with-border-cross"! May be "...will capture; will move
pointer to blue"?

https://codereview.chromium.org/1809603003/diff/60001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/virtual/pointerevent/fast/events/pointerevents/mouse-pointer-capture-transition-events-expected.txt:43:
blue received pointermove
This moves confused me, please make the step description clear:
*** Move out of grey, then release button ***

https://codereview.chromium.org/1809603003/diff/60001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/virtual/pointerevent/fast/events/pointerevents/mouse-pointer-capture-transition-events.html
(right):

https://codereview.chromium.org/1809603003/diff/60001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/virtual/pointerevent/fast/events/pointerevents/mouse-pointer-capture-transition-events.html:80:
if (borderCross) {
Nit: tab char.

https://codereview.chromium.org/1809603003/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/input/PointerEventManager.cpp (right):

https://codereview.chromium.org/1809603003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/input/PointerEventManager.cpp:119: if
(isFrameBoundaryTransition && pointerEvent->buttons() == 0) {
Add a comment why we can't omit |isFrameBoundary...| check here.

https://codereview.chromium.org/1809603003/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/input/PointerEventManager.h (right):

https://codereview.chromium.org/1809603003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/input/PointerEventManager.h:47: // only when the
transition is beyond the document boundary which is specified
The last line is not clear to me, should perhaps say what the function is doing
with it.

Should we rename the param to |setPointerPosition|?

https://codereview.chromium.org/1809603003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/input/PointerEventManager.h:103: // if necessary.
Comment on the |setPointerPosition| param.

[Navid Zolghadr, 2016-03-23 19:47:48]

ptal

https://codereview.chromium.org/1809603003/diff/60001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/virtual/pointerevent/fast/events/pointerevents/mouse-pointer-capture-transition-events-expected.txt
(right):

https://codereview.chromium.org/1809603003/diff/60001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/virtual/pointerevent/fast/events/pointerevents/mouse-pointer-capture-transition-events-expected.txt:6:
==== 'none' is capturing and then 'blue' will capture with border cross ====
On 2016/03/23 18:49:07, mustaq wrote:
> I read "...will capture-with-border-cross"! May be "...will capture; will move
> pointer to blue"?

Done.

https://codereview.chromium.org/1809603003/diff/60001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/virtual/pointerevent/fast/events/pointerevents/mouse-pointer-capture-transition-events-expected.txt:43:
blue received pointermove
On 2016/03/23 18:49:07, mustaq wrote:
> This moves confused me, please make the step description clear:
> *** Move out of grey, then release button ***

Done.

https://codereview.chromium.org/1809603003/diff/60001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/virtual/pointerevent/fast/events/pointerevents/mouse-pointer-capture-transition-events.html
(right):

https://codereview.chromium.org/1809603003/diff/60001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/virtual/pointerevent/fast/events/pointerevents/mouse-pointer-capture-transition-events.html:80:
if (borderCross) {
On 2016/03/23 18:49:07, mustaq wrote:
> Nit: tab char.

Done.

https://codereview.chromium.org/1809603003/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/input/PointerEventManager.cpp (right):

https://codereview.chromium.org/1809603003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/input/PointerEventManager.cpp:119: if
(isFrameBoundaryTransition && pointerEvent->buttons() == 0) {
On 2016/03/23 18:49:07, mustaq wrote:
> Add a comment why we can't omit |isFrameBoundary...| check here.

Done.

https://codereview.chromium.org/1809603003/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/input/PointerEventManager.h (right):

https://codereview.chromium.org/1809603003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/input/PointerEventManager.h:47: // only when the
transition is beyond the document boundary which is specified
On 2016/03/23 18:49:07, mustaq wrote:
> The last line is not clear to me, should perhaps say what the function is
doing
> with it.
> 
> Should we rename the param to |setPointerPosition|?

I changed the wording of the last sentence. Does it look better? The variable
name used to be setPointerPosition but I changed it to this as from the caller
of this function point of view he doesn't know when the pointer needs to be set
or not. EventHandler just knows whether this is for going across the boundary of
the iframe or not. That is the decision of this class to use this information to
set the pointer event node. Is that okay?

https://codereview.chromium.org/1809603003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/input/PointerEventManager.h:103: // if necessary.
On 2016/03/23 18:49:07, mustaq wrote:
> Comment on the |setPointerPosition| param.

Done.

[mustaq, 2016-03-23 20:02:33]

Still lgtm.

https://codereview.chromium.org/1809603003/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/input/PointerEventManager.h (right):

https://codereview.chromium.org/1809603003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/input/PointerEventManager.h:47: // only when the
transition is beyond the document boundary which is specified
On 2016/03/23 19:47:48, Navid Zolghadr wrote:
> On 2016/03/23 18:49:07, mustaq wrote:
> > The last line is not clear to me, should perhaps say what the function is
> doing
> > with it.
> > 
> > Should we rename the param to |setPointerPosition|?
> 
> I changed the wording of the last sentence. Does it look better? The variable
> name used to be setPointerPosition but I changed it to this as from the caller
> of this function point of view he doesn't know when the pointer needs to be
set
> or not. EventHandler just knows whether this is for going across the boundary
of
> the iframe or not. That is the decision of this class to use this information
to
> set the pointer event node. Is that okay?

Yes, this is clear now.

[Rick Byers, 2016-03-29 16:37:14]

LGTM with nit

There are some active debates about the desired behavior here
(https://github.com/w3c/pointerevents/issues/35), but gathering data on the
compatibility of our preferred design is important in helping to resolve those
debates.  So I think landing this now while the debate is outstanding is great.

https://codereview.chromium.org/1809603003/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/input/EventHandler.h (right):

https://codereview.chromium.org/1809603003/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/input/EventHandler.h:314: void
updateMouseEventTargetNodeAndSendEvents(Node*, const PlatformMouseEvent&, bool =
false);
nit: name the parameter here since the name defines the contract in this case
(we omit names only when they're redundant with the type IIRC).

https://codereview.chromium.org/1809603003/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/input/PointerEventManager.h (right):

https://codereview.chromium.org/1809603003/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/input/PointerEventManager.h:47: // only when
isFrameBoundaryTransition is true which indicates the
nit: can you add a little more detail on why the frame boundary case needs to be
treated specially?  Naively I think frame and element boundary would ideally be
implemented identically.

[Navid Zolghadr, 2016-03-29 17:44:03]

https://codereview.chromium.org/1809603003/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/input/EventHandler.h (right):

https://codereview.chromium.org/1809603003/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/input/EventHandler.h:314: void
updateMouseEventTargetNodeAndSendEvents(Node*, const PlatformMouseEvent&, bool =
false);
On 2016/03/29 16:37:14, Rick Byers wrote:
> nit: name the parameter here since the name defines the contract in this case
> (we omit names only when they're redundant with the type IIRC).

Done.

https://codereview.chromium.org/1809603003/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/input/PointerEventManager.h (right):

https://codereview.chromium.org/1809603003/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/input/PointerEventManager.h:47: // only when
isFrameBoundaryTransition is true which indicates the
On 2016/03/29 16:37:14, Rick Byers wrote:
> nit: can you add a little more detail on why the frame boundary case needs to
be
> treated specially?  Naively I think frame and element boundary would ideally
be
> implemented identically.

I explained a bit more here in this comment. Essentially the normal mouse events
(down/move/up) never come to this function. They will go to
sendMousePointerEvent and the transition events of those will be handled there.

[Navid Zolghadr, 2016-03-29 18:58:29]

The CQ bit was checked by nzolghadr@chromium.org

[Navid Zolghadr, 2016-03-29 18:58:30]

The patchset sent to the CQ was uploaded after l-g-t-m from mustaq@chromium.org,
rbyers@chromium.org
Link to the patchset: https://codereview.chromium.org/1809603003/#ps100001
(title: "Better comment")

[commit-bot: I haz the power, 2016-03-29 18:58:47]

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

[commit-bot: I haz the power, 2016-03-29 19:04:30]

Committed patchset #6 (id:100001)

[commit-bot: I haz the power, 2016-03-29 19:05:36]

Description was changed from

==========
Separate mouse transition events from pointerevent

This CL will separate sending mouse transition events
from pointer events (with type=mouse) transitions as they might belong
to different node anyway. This allows us more separation
of mouse event and pointer events.

BUG=587955
==========

to

==========
Separate mouse transition events from pointerevent

This CL will separate sending mouse transition events
from pointer events (with type=mouse) transitions as they might belong
to different node anyway. This allows us more separation
of mouse event and pointer events.

BUG=587955

Committed: https://crrev.com/fd312312165253f96bd75c19716444805fadf087
Cr-Commit-Position: refs/heads/master@{#383787}
==========

[commit-bot: I haz the power, 2016-03-29 19:05:38]

Patchset 6 (id:??) landed as
https://crrev.com/fd312312165253f96bd75c19716444805fadf087
Cr-Commit-Position: refs/heads/master@{#383787}