[uievents] Specify MouseEvent.which (#35)

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27558

##### Philip Jägenstedt 2014-12-10 22:40:04 UTC
Every browser I tested supports this.

In Gecko it's simply button + 1.

In Blink/WebKit it's button + 1 except when button is 65535, in which case it's explicitly wrapped around to 0. This is odd and probably doesn't matter.

I suggest spec'ing the Gecko behavior.

##### Comment 1 Arthur Barstow 2015-03-21 15:12:08 UTC
Bulk move of all D3E bugs to the UI Events component.

##### Comment 2 Philip Jägenstedt 2015-07-10 12:06:29 UTC
Ping?

Usage is very high:
https://www.chromestatus.com/metrics/feature/timeline/popularity/595

In Gecko and WebKit, which is on the UIEvent prototype only.

That was previously the case in Blink as well, but I added it to MouseEvent and KeyboardEvent to shadow the one on UIEvent in order to measure the usage for non-mouse/keyboard events where it always returns 0:
https://www.chromestatus.com/metrics/feature/timeline/popularity/598

In IE, it looks like which is on the KeyboardEvent and MouseEvent prototype only, not on UIEvent.

Moving it up to UIEvent or adding it to MouseEvent would be OK, and the difference is in who gets to take the risk when aligning with the spec.

##### Comment 3 Rick Byers 2015-07-10 13:29:12 UTC
This sounds like the always-0 UIEvent.pageX/pageY difference Ted (IE team) reported caused an actual compatibility issue for them: https://groups.google.com/a/chromium.org/d/msg/input-dev/4p1XZy_17aw/qi-LQuOtvpcJ

So I think it's worth trying to align the Gecko, Blink, Webkit and Edge behavior here.

I don't really trust the use-counter data here as a reliable indicator of risk - I suspect most uses will do just as fine with undefined as they did with 0.  But I don't have any hard data.  If blink's pageX/pageY change goes smoothly, then I'd be willing to try moving 'which' as well.

Alternately just standardizing it on UIEvent is the simpler option, so fine with me also.  It's a little uglier, but 'which' is going to be ugly no matter what way we look at it.

Ted, any thoughts?

If we can get some agreement between vendors here, then I suggest we make a concrete pull-request to the UIEvents spec.

##### Comment 4 Philip Jägenstedt 2015-07-10 13:43:45 UTC
Boris, Olli, looks like you've both poked at these three interfaces in Gecko from time to time. What say you?

##### Comment 5 Olli Pettay 2015-07-10 13:50:53 UTC
Keeping it in UIEvent kind of makes sense since more than one interface extending UIEvent want .which.
Also, .which has been in UIEvent forever, so I don't see strong reasons to move it.

But I don't strongly object to move it to Mouse/Keyboard events either.
Just don't quite see the point of making the change for the sake of change -
the API isn't significantly better or worse wherever .which lives.

##### Comment 6 Philip Jägenstedt 2015-07-10 13:55:35 UTC
I agree that would be a quicker way to getting everything aligned and forgetting about this. Anyone from Microsoft have a problem with moving it up to UIEvent in IE?

##### Comment 7 Rick Byers 2015-07-10 14:03:26 UTC
Yeah that was my initial reaction too (i.e. unlike pageX/pageY - which really does have meaning on more than one type of UIEvent).  However the meaning is completely different depending on the interface.  It's pretty odd to have API docs like:

UIEvent.which:
 - on KeyboardEvent this is the key code.  On MouseEvent it's the button pressed.

Makes a lot more sense to just have separate docs on MouseEvent and KeyboardEvent (which MDN does have by the way - with the docs for UIEvent.which being incomplete).

Also I just checked to see if I could find an example of a site accessing 'which' for a non-keyboard non-mouse event.  I immediately found this code in GMail operating on a FocusEvent ('a'):

        for (c in a)
            b[c] = a[c];

So again (like the discussion here: https://groups.google.com/a/chromium.org/d/msg/blink-dev/pjohnl9znQQ/eHvq4U6E2skJ) access is due to an event library attempting to make a copy of the event.

But I agree with Olli that it may not be worth the effort.  Anyone from IE want to weigh in since they'd be the one that would have to change?

##### Comment 8 Travis Leithead [MSFT] 2015-07-10 17:56:06 UTC
In IE/Edge, which is implemented on MouseEvent and KeyboardEvent. Moving it to the UIEvent interface exposes it to many other interfaces that don't really need it. Since this is a compatibility API, I'd prefer not to spec it on UIEvent directly.

##### Comment 9 Philip Jägenstedt 2015-07-10 18:00:23 UTC
As I said, I'm OK either way, but I'll assume then that the spec will have MouseEvent.which soonish and that we should try to remove it from the UIEvent prototype.

##### Comment 10 Rick Byers 2015-07-10 18:15:27 UTC
That's fine with me.  Spec it on MouseEvent and KeyboardEvent and we'll attempt to move it in blink.  Of course if we hit compat issues then we'll have to have to talk :-).  But if Edge hasn't already had compat issues here, then I'm sure it'll be fine.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/uievents/issues/35