Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Value of button attribute for pointermove event #33

Closed
bethge opened this issue Jan 31, 2016 · 14 comments

Comments

Projects
None yet
5 participants
@bethge
Copy link

commented Jan 31, 2016

We have noticed an inconsistency when it comes to the button attribute of a pointermove event (jquery/PEP#267).

In IE 11 and Edge, any pointermove, that does not express a button state transition, has button: -1.

In OSX and Win - FF 44 (with flag) a pointermove's button attribute mirrors the mousemove's button attribute, with the extension of button: -1, if no button is pressed.

According to the specification: https://www.w3.org/TR/pointerevents/#chorded-button-interactions button and buttons are inherited from: https://www.w3.org/TR/DOM-Level-3-Events/#attributes-2, which states:

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.

Is there an expected value of button for a pointermove with a button pressed and no button state transition? Is button: -1 the new un-initialized value?

The current situation for mousemove is quite diverse and varies across OS and browsers, with button: 0 for Win IE and Win FF and button: 0/1/2 (matching the currently pressed button) for OSX Safari, OSX FF, OSX CH and Win CH. Might PE be an opportunity to form a consistent behaviour?

P.S.: The same holds for pointerenter, pointerover, pointerleave and pointerout.

@RByers

This comment has been minimized.

Copy link
Contributor

commented Feb 1, 2016

I agree the spec doesn't seem entirely clear here. In my reading, pointermove's button should be -1 when no buttons are pressed, and the previous value otherwise (as for mousemove). So it seems like an Edge bug. @teddink WDYT?

But yes, the -1 on pointermove vs. 0 on mousemove difference is intentional.

@RByers

This comment has been minimized.

Copy link
Contributor

commented Feb 1, 2016

I should add that as far as I can see this property doesn't matter much one way or the other - there's not much value in reading the button value of a pointermove event (should probably be using buttons instead for any real use case). So I'd personally also be happy to update the spec to match Edge's behavior and ask Mozilla to change.

Did you have a particular use case in mind?

@bethge

This comment has been minimized.

Copy link
Author

commented Feb 1, 2016

I have mulled it over some more and I feel like I now fully grasp the implications of this line:

[...]. In order to facilitate differentiating button state transitions in any pointer event (and not just pointerdown and pointerup), the button property takes on a new value when no mouse buttons are depressed: [...]

Iiuc, since chorded button interactions do not trigger pointerdown and pointerup events, a pointerevent e with e.button > -1 would be the only way to identify a button state transition (without using external state).
When mirroring mousemove, I cannot see a way to tell apart a button state transition from a change in position.

Edge's behaviour would make it a lot easier to only trigger a function if the (chorded) button state changes.

@teddink

This comment has been minimized.

Copy link

commented Feb 1, 2016

Upon consultation with the developer that owns this area for Edge, I believe bethge gets it with his last response. When a pointerevent is triggered by a button change, event.button will have that value.

So for non-chorded case, pointerdown/pointerup will have the button that was pressed/lifted, but when the mouse is moved while the button is down, the button doesn’t trigger those events, so button is -1, the default value.

For chorded case, a chorded press will trigger a pointermove event, so event.button will be the newly pressed button. As bethge mentioned, without this you would need to keep track of extra state to figure out which button press caused the pointermove.

@patrickhlauke

This comment has been minimized.

Copy link
Member

commented Feb 1, 2016

is there a need for some further clarification in the wording of the spec, do we feel?

@smaug----

This comment has been minimized.

Copy link
Contributor

commented Feb 1, 2016

As bethge mentioned, without this you would need to keep track of extra state to figure out which button press caused the pointermove.

But if button is -1, you need to track the actual button state somewhere.
Feels really odd behavior to me.

(I feel like I'm misunderstanding something here)

@RByers

This comment has been minimized.

Copy link
Contributor

commented Feb 1, 2016

Ah, that makes sense @bethge / @teddink, thanks.

But if button is -1, you need to track the actual button state somewhere.

Why? Isn't that what buttons is for? It makes sense to me that button describes state transitions, and buttons describes the current state. The combination of the two (with button=-1 for EVERY pointermove where there is no button state change) let you fully understand the current state and any state transitions without tracking any additional state yourself.

If we agree that this makes sense, I think we definitely need to change the spec to describe it - it's definitely not clear. This text is wrong / misleading:

the button property takes on a new value when no mouse buttons are depressed:

Instead it should say something like "the button property has the value -1 when the button state has not changed from the previous pointermove event". Maybe also add the clarifying text "This way button indicates which button has been pressed or released, while buttons represents the state of all buttons after any such transition". We also need a test for this.

/cc @mustaqahmed, IIRC we'll need to make changes in blink for this too.

@smaug----

This comment has been minimized.

Copy link
Contributor

commented Feb 2, 2016

So the meaning of pointermove starts to drift away from the 'move' case towards something like "move" or "button state change". I guess I could live with that, even though it is not too pretty API.
Sounds like .button + move event is used for something like pointerbuttonchange here.

@patrickhlauke

This comment has been minimized.

Copy link
Member

commented Feb 2, 2016

wasn't pointermove already more of a "something changed", as it's also fired if pressure, tiltX/tiltY or width/height changes?

@smaug----

This comment has been minimized.

Copy link
Contributor

commented Feb 2, 2016

it is fired for those changes, but those keep the changed value in the events fired after the change. Those properties represent a part of the state in which the pointer is.
.button is (assuming we have -1 after the initial event) this unusual property that it doesn't indicate any state. It just tells if there was a change since the previous event.

When .buttons was added to mouseevents it was supposed to be the .button as .button should have been since the beginning.

But as I said, I can live with .button being weird thing, since it has been broken anyhow forever for mouseevents (value 0 handling for left button)

@RByers

This comment has been minimized.

Copy link
Contributor

commented Feb 2, 2016

Yeah, we had a bikeshed at one point about renaming pointermove to pointerchange since that was more accurate, but agreed that consistency with what IE shipped probably trumped that relatively minor concern. These chorded scenarios are pretty niche already, I think most developers are better served by not having to really worry about them most of the time (in contrast to mouse events). Still, I agree it's a little awkward and confusing.

Updating the summary to reflect the conclusion of what needs to happen here.

@patrickhlauke

This comment has been minimized.

Copy link
Member

commented Mar 5, 2016

@bethge do the changes from #34 address your original concern, i.e. do they close this issue?

@bethge

This comment has been minimized.

Copy link
Author

commented Mar 5, 2016

Yes, very much so, appreciate it. Feel free to close this issue.

@patrickhlauke

This comment has been minimized.

Copy link
Member

commented Mar 5, 2016

Super, thank you :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.