Set button property to -1 if no mouse button is depressed.

[Steditor]

Fixes #173 by setting the button property to -1 if buttons is 0, indicating that no button is depressed.

I couldn't find anything in the recommendation on the expected value of button in events other than pointerup and pointerdown. In theory, we could add more events, in which the button property contains correct data: Whenever only one button is depressed, we could set the button value to the current depressed button by reverse-mapping buttons. But as this would still leave us with loads of situations, in which one cannot use the button property, I decided against patching it for all possible cases.
Any thoughts on that?

In addition, this PR adds to #243 as PEP now not only detects an incorrect buttons state, but also fixes it.

[bethge]

I may have this the wrong way around - I understand the spec the following:

• Left Mouse down: button: 0 - buttons: 1
• Left Mouse up: button: 0 - buttons: 0
• Right Mouse down: button: 2 - buttons: 2
• Right Mouse up: button: 2 - buttons: 0
• Mouse move/out/over/enter/leave with no button pressed: button: -1 - buttons: 0

In https://www.w3.org/TR/DOM-Level-3-Events/#attributes-2:

The value of button is not updated for events not caused by the depression/release of a mouse button. In these scenarios, take care not to interpret the value 0 as the left button, but rather as the un-initialized value.

I feel like pointerevents mean to give the button property of move/out/over/enter/leave events a meaning. Yet, everything beyond the cases above appears to be very inconsistent across browsers:

On IE 11 Win7:

• pointermove with the left, right or no mouse button pressed: button: -1
• Chorded button interactions:
  • Press and hold left, press and hold right: The press right triggers one pointermove with button: 2. Moving the cursor with these two buttons still pressed, triggers pointermove with button: -1.
  • Press and hold right, press and hold left: The press left triggers one pointermove with button: 0. Moving the cursor with these two buttons still pressed, triggers pointermove with button: -1.

On FF44 - OS X (with flag):

• pointermove with no mouse button pressed: button: -1
• pointermove with the left mouse button pressed: button: 0
• pointermove with the right mouse button pressed: button: 2
• Chorded button interactions:
  • Press and hold left, press and hold right: The press right triggers one pointerdown with button: 2. Moving the cursors with these two buttons still pressed, triggers pointermove with button: 0.
  • Press and hold right, press and hold left: The press left triggers one pointerdown with button: 0. Moving the cursors with these two buttons still pressed, triggers pointermove with button: 0.

Would be great if someone could confirm these inconsistencies. I used this fiddle for testing: http://jsbin.com/buxabi/31/edit?js,output

For now, we could try to make sure that the events: mousemove, mouseout, mouseover, mouseenter and mouseleave with no button pressed, have: button: -1.

[Steditor]

Thats exactly the ambiguity I also encountered. I have the same outputs with you in FF44 / Win10 (like your FF) and IE/Edge / Win10 (like your IE).

I feel -1 should only be the value of button, iff no button is depressed, I find the behaviour of IE/Edge strange: the Level 3 events spec states that 0 should be the uninitialized value and PointerEvents inherit this behaviour imho.
Whilst this has always been strange as 0 at the same time could indicate the primary button, using -1 as uninitialized value for PointerEvents seems even stranger to me.

This PR should produce the output you also suggested:button: -1 for all move/... events with no button pressed. All other cases are right now simply left to the browser and will therefor mirror the user agents' inconsistencies.

[patrickhlauke]

it might be worth bringing up the ambiguity over here https://github.com/w3c/pointerevents (admittedly, i've not delves into the button / buttons thing, so haven't even tried to disambiguate what's going on)

[bethge]

@Steditor: Ah yes, great! Sorry, I first thought you update the button property on the mousedown event. The GitHub diff view threw me off a bit.

Thanks for testing the other browsers!

You can activate the existing functional test for this: https://github.com/jquery/PEP/blob/b4be88d/tests/intern.js#L30-L31 .

After that: lgtm

@patrickhlauke: Good point. I have been wondering why there are no web-plattform-tests to enforce a consistent behaviour for this, although chorded button interactions have their own paragraph in the spec.

[Steditor]

I have now activated the functional test.
(which by the way passes on all my browsers. Chrome needed a little push, as it somehow was not able to resolve the encoded url ..%5C..%5Cdist%5Cpep.js - is it intentional, that the injection of the script into the w3c html test files uses encoded backslashes instead of normal slashes? All other dependencies of those test files simply use / as delimiter.)

[bethge]

Over at w3c/pointerevents#33 the button topic got clarified and a rewording of the spec is underway.

In short, only a pointermove that is triggered by a chorded button interaction has button > -1, all other pointermove have button == -1. pointerover,pointerout,pointerleave and pointerenter basically always have button == -1 (I hope I am not forgetting some edge cases).

In mouse-world chorded button interactions do trigger mousedown and mouseup, so basically those are the only ones causing button > -1.

@Steditor do you possibly have time to update your PR accordingly?

[Steditor]

Thank you for the clarification!
I'm on it now to update the PR.

[Steditor]

Ok, now we have button: -1 for mousemove/mouseover/mouseout and pass through the original value of button for mousedown and mouseup, indicating the button that changed (This happens through dispatcher.cloneEvent like before).

I guess we need a WPT-test for this before the PR can be merged?

[scottgonzalez]

is it intentional, that the injection of the script into the w3c html test files uses encoded backslashes instead of normal slashes?

Can you point to the code you're referring to? I don't see any encoded paths in the code.

[scottgonzalez]

I guess we need a WPT-test for this before the PR can be merged?

We should certainly make sure WPT has assertions to cover this, but I'm fine with merging before that whole roundtrip can happen.

[Steditor]

Can you point to the code you're referring to? I don't see any encoded paths in the code.

In tests\support\pretest.js the function modFile adds the PEP-specific scripts to the W3C test files.
It uses encodeURI to encode the path - which is fine with slashes, but the node path module produces backslashes on Windows, which are then encoded as %5C.

[scottgonzalez]

Ah, I was searching the code for the actual encoded characters. @jdalton is the one who did that. It seems like it should be safe without that.

[bethge]

@robfitz273k Could you elaborate on the problem you are experiencing with Firefox 44 on desktop? What mouse buttons do you press, in which order and what is expected/actual?

This fiddle uses the current state of this PR: http://jsbin.com/buxabi/38/edit?html,js,output.

[robfitz273k]

Current behaviour with: http://jsbin.com/buxabi/38/edit?html,js,output.

Mouse action	event	button	buttons
Press and hold left mouse button	pointerdown	0	1
Press and hold right mouse button	pointermove	2	3
Release right mouse button	pointermove	2	3
Release left mouse button	pointerup	0	0

Expected:

Mouse action	event	button	buttons
Press and hold left mouse button	pointerdown	0	1
Press and hold right mouse button	pointermove	2	3
Release right mouse button	pointermove	2	1
Release left mouse button	pointerup	0	0

With the current proposed fix we can't tell the state change between the second and third action, was it a button press or button release.

Changing this line
if (e.buttons === BUTTON_TO_BUTTONS[e.button]) { e.buttons = 0; }
to this seems to work.
if (e.buttons & BUTTON_TO_BUTTONS[e.button]) { e.buttons &= ~BUTTON_TO_BUTTONS[e.button] }

[Steditor]

@robfitz273k I have now decided to simply clear the bit - if it hadn't been set, nothing changes anyway.
Does the PR now behave as expected for you?

[robfitz273k]

@Steditor yes that's working as expected now.

[bethge]

@robfitz273k Thank you for the detailed description! Tried it on Ubuntu 14.04 with FF 44 and have the same issue with PEP-4.1.

@Steditor Good idea to swap the bit. Works like a charm.

[robfitz273k]

Testing the touch behaviour of http://jsbin.com/buxabi/38/edit?html,js,output with Firefox 44 on my Android phone.

Current:

Touch action	event	button	buttons
Start	pointerdown	0	1
Move	pointermove	0	1
Move	pointermove	0	1
End	pointerup	0	0

Expected:

Touch action	event	button	buttons
Start	pointerdown	0	1
Move	pointermove	-1	1
Move	pointermove	-1	1
End	pointerup	0	0

I can get this result by adding the line event.button = -1; to the moveOverOut function in touch.js. But this also effects the pointerover and pointerout events so I'm not sure if that's correct.

[Steditor]

I'd suggest to fix this in a separate PR as this PR only dealt with MouseEvents as source so far.