event.which not consistent across browsers for keydown event

[[email protected]…]

Try the example at ​http://api.jquery.com/keydown/ Try it with Google Chrome (Linux) press the keys "+" and "-" (NOT on numerik keypad)

Now try it with Mozilla Firefox (linux) press the keys "+" and "-" (NOT on numerik keypad)

Watch the event's "which" property

Expected: the value of .which should be the same on both browsers for the same key.

Observed: On Chrome, for the + key: which=187

for the - key: which=189

On Firefox:for the + key: which=171

for the - key: which=173

[dmethvin]

I don't have access to that OS+Browser combination.

What is the expected value?

Is that value present in any of the standard properties of the DOM event object?

[trac-o-bot]

Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!

[[email protected]…]

I have no idea which is the expected value, but it should be consistent across browsers, that's what the jQuery API claims: "While browsers use differing properties to store this information, jQuery normalizes the .which property so you can reliably use it to retrieve the key code."

------ Output from Chrome ("+" key) ------

Handler for .keydown() called 1 time(s).
{
originalEvent: [object KeyboardEvent],
type: keydown,
timeStamp: 1397476836189,
jQuery110208109870944172144: true,
keyCode: 187,
key: undefined,
charCode: 0,
char: undefined,
which: 187,
view: [object Window],
target: <input id="target">,
shiftKey: false,
relatedTarget: undefined,
metaKey: false,
eventPhase: 2,
currentTarget: <input id="target">,
ctrlKey: false,
cancelable: true,
bubbles: true,
altKey: false,
delegateTarget: <input id="target">,
handleObj: [object Object],
data: null,

----- Output from Firefox ("+" key)-----
Handler for .keydown() called 1 time(s).
{
originalEvent: [object KeyboardEvent],
type: keydown,
timeStamp: 153805815,
jQuery110206712352453989763: true,
keyCode: 171,
key: MozPrintableKey,
charCode: 0,
char: undefined,
which: 171,
view: [object Window],
target: <input id="target">,
shiftKey: false,
relatedTarget: undefined,
metaKey: false,
eventPhase: 2,
currentTarget: <input id="target">,
ctrlKey: false,
cancelable: true,
bubbles: true,
altKey: false,
delegateTarget: <input id="target">,
handleObj: [object Object],
data: null,

--- PLEASE REOPEN this is a huge issue

[dmethvin]

Your output shows that the two browsers disagree on keyCode. There's nothing jQuery can do about that, we can only normalize the information they provide. Or do you have some suggestion about how to do this?

If this SO thread is correct it sounds like you should report a bug to Firefox: ​http://stackoverflow.com/questions/10822100/determine-if-plus-key-in-keydown-is-from-the-numpad

[teo1978]

OMG I hadn't realized you have closed this.

Your output shows that the two browsers disagree on keyCode. There's nothing jQuery can do about that, we can only normalize the information they provide. Or do you have some suggestion about how to do this?

Yes, OBVIOUSLY. Maintain handmade per-browser keycode maps to convert from wrong browser-specific codes to standard key codes consistent across browsers.

From: ​http://api.jquery.com/keydown/ "While browsers use differing properties to store this information, jQuery normalizes the .which property so you can reliably use it to retrieve the key code." From that, I expect jQuery to take the responsibility to guarantee consistent cross-browser key codes. Otherwise why am I using .which in the first place? If I wanted raw low-level browser-provided nonstandard garbage, I would use the browser's low level properties, or I wouldn't even use jQuery in the first place.

Just as jQuery simulates mouseover and mouseout (or some of those, don't remember exactly) that are not present on all browsers, for the sake of cross-browserness, why shouldn't it also correct key code inconsistencies?