Clarify click event firing for chorded buttons

[mustaqahmed]

The UI Event Spec says:

The click event should only be fired for the primary pointer button (i.e., when MouseEvent.button value is 0, MouseEvent.buttons value is 1). Secondary buttons (like the middle or right button on a standard mouse) must not fire click events.

We need to clarify what it means for chorded buttons. For example, should we fire a click in any of these sequences?

1. L-button-down (=> pointerdown),
   M-button-down (=> pointermove),
   L-button-up (=> pointermove),
   M-button-up (=> pointerup).
2. M-button-down (=> pointerdown),
   L-button-down (=> pointermove),
   L-button-up (=> pointermove),
   M-button-up (=> pointerup).

The spec is not clear here. If we agree that none of the above sequences fire clicks, then the spec can say:

A click is fired only for a "pointerdown with button=0" followed by a "pointerup with button=0".

Otherwise, it can define click to be a function of primary button activity:

A click is fired for a "pointerdown/pointermove with button=0 that sets the LSB of buttons" followed by a "pointerup/pointermove with button=0 that resets the LSB of buttons".

[patrickhlauke]

does PE need to define this, or is a reference (or maybe even a non-normative note quoting that extract) to the UI Event Spec sufficient? just asking because click itself isn't necessarily part of PE itself, to my mind. and if the UI Event Spec isn't saying anything directly about chorded buttons, should that spec be nudged to do it for us? (i.e. submit a comment/patch/PR to UI Event Spec to include clarification about chorded buttons)

[mustaqahmed]

You are right that click is not a core part of PE. But since "chorded buttons" is a PE-specific concept, and the cases I mentioned above involve both click and "chorded buttons", I don't see a way to refer to UI Event Spec to clarify them. On the other hand, since the PE Spec overrides parts of the UI Event Spec, it is logical to override the click definition here as well.

[RByers]

Agreed on the call that we should add a note for this, and that either option is probably OK. To @teddink to test what Edge does and confirm they're happy with the behavior. Absent other arguments, we can just spec what Edge is already doing.

[teddink]

Here is my sample: http://output.jsbin.com/yimako

TEST 1 - In the blue box, perform the following:
Left click
Middle click
Left release
Middle release

Results on Edge -

pointerdown with button = 0 buttons = 1
pointermove with button = 1 buttons = 5
pointermove with button = 0 buttons = 4
click with button = 0 buttons = 4
pointerup with button = 1 buttons = 0

Results on Chrome Canary with PE on –
pointerdown with button = 0 buttons = 1
pointermove with button = 1 buttons = 5
pointermove with button = 0 buttons = 4
click with button = 0 buttons = 4
pointerup with button = 1 buttons = 0

TEST 2 - Then try this:
Left click
Middle click
Middle release
Left release

Results on Edge –
pointerdown with button = 0 buttons = 1
pointermove with button = 1 buttons = 5
pointermove with button = 1 buttons = 1
pointerup with button = 0 buttons = 0

Results on Chrome Canary with PE on –
pointerdown with button = 0 buttons = 1
pointermove with button = 1 buttons = 5
pointermove with button = 1 buttons = 1
click with button = 1 buttons = 1
pointerup with button = 0 buttons = 0

Chrome appears to have a bug on Test 2 since click is firing for a non-primary button. Out preference would be to just specify the Edge behavior, but are open to discussing options to changing the current behavior that Edge has on Test 2. The reason that Edge does not fire a click event for the primary button in Test 2 is that we have chosen to intertwine 'click' and CSS :active in our implementation.

[RByers]

Discussed on the call today. We agree this is out of scope of Pointer Events. PE shouldn't be modifying the semantics of when click fires - that's up to UI Events. @NavidZ is going to file an issue for UI Events saying that it should perhaps add a note clarifying that changes in other (non-primary) buttons is irrelevant.

Note that Chrome still has a long outstanding bug here that we're in the process of trying to fix - we fire click when any button is lifted. When fixed, TEST 2 above will behave as follows:

pointerdown with button = 0 buttons = 1
pointermove with button = 1 buttons = 5
pointermove with button = 1 buttons = 1
pointerup with button = 0 buttons = 0
click with button = 0 buttons = 0

[teddink]

I put in this Edge bug for tracking the work to match the Chrome intended implementation: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/8095809/