537955 - Javascript onKeyDown wrong keyCode from '=' key

Status: RESOLVED INVALID

(Core :: Widget: Win32, defect)

Description

[proxy.idrin]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; pl; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; pl; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6

KeyCode from onKeyDown event is 107 with '=' key. But code 107 is Numpad + not '=' key. Correct keyCode from '=' key is 187.

Reproducible: Always

Steps to Reproduce:
1. Go on given page (keyCode test page)
2. Focus on Input element
3. Press only '=' key and make sure that '=' key is pressed last
4. Read event.keyCode from onKeyDown event
Actual Results:  
We can see wrong 107 keyCode from '=' key. In this case the Numpad + key and '=' key is treat as same one!

Expected Results:  
Make it 187.

Javascript keyCode table is different from the ASCII. The full list of keyCodes we for example have here: http://www.cambiaresearch.com/c4/702b8cd1-e5b0-42e6-83ac-25f0306e3e25/Javascript-Char-Codes-Key-Codes.aspx

Comment 1

[Boris Zbarsky [:bzbarsky]]

I see "61" as the keycode for '=', as expected.  What key are you using to get '107', and why are you expecting '187'?

Also, are you seeing this on trunk too?  Or just in 1.9.1?

Comment 2

[Jim Mathies [:jimm]]

odd -
Chrome:
onKeyDown	onKeyPress	onKeyUp
event.keyCode	'187'	'61'	'187''9'
event.charCode	'0'	'61'	'0''0'
event.which	'187'	'61'	'187''9'

Fx nightly:
onKeyDown 	onKeyPress 	onKeyUp
event.keyCode 	'107' 	'0' 	'107'
event.charCode 	'0' 	'61' 	'0'
event.which 	'107' 	'61' 	'107'

Comment 3

[Jim Mathies [:jimm]]

IE:

 onKeyDown onKeyPress onKeyUp 
event.keyCode '187' '61' '187' 
event.charCode 'undefined' 'undefined' 'undefined' 
event.which 'undefined' 'undefined' 'undefined'

Comment 4

[Boris Zbarsky [:bzbarsky]]

IE uses a totally different key event model in any case.

I'd still love to know where the 107 and 187 come from... ;)

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

107 is 0x6B which is VK_ADD.

187 is 0xBB which is VK_OEM_PLUS.

We shouldn't use 0x6B for normal '+' key because VK_ADD is used for '+' key on NumPad. However, 187 doesn't mean '=' key. It means '+' inputtable key on any keyboard layout *on* Windows.

This should be marked as INVALID. There is no standard spec in W3C for keyCode. They gave up to define them. Maybe, due to backward compatibility and browser compatibility. And also, we shouldn't be hung up on the compatibility with other browsers for keyCode. That breaks the compatibility with other keyboard layouts and other platform's Gecko.

Web developer should use consts of KeydownEvent. Like DOM_VK_* which is defined in nsIDOMKeyEvent.idl.
http://mxr.mozilla.org/mozilla-central/source/dom/interfaces/events/nsIDOMKeyEvent.idl

See also bug 631165 and bug 630810. We will use DOM_VK_EQUALS (0x3D, 61) for "=/+" key on US keyboard layout. However, e.g., on Japanese keyboard layout, '-/=' becomes DOM_VK_HYPHEN_MINUS (0xAD, 173) and ';/+' becomes DOM_VK_SEMICOLON (0x3B, 59). This rule (decide the keycode from unshifed character) is simple. This means we can make compatibility between most platforms on Gecko. On the other hand, IE and Chrome uses native keycode for the DOM keycode. Which means their other platforms cannot compute perfectly the OEM keycode on other platforms. E.g., Chrome sends 0xBB (187) for ';/+' key on Japanese keyboard layout and 0xBD (189) for '-/=' key. On Mac, chrome sends 0xBA (186) and 0xBD (189) for same keys on Japanese keyboard layout.

We should implement DOM 3 key property which have clearer rules. It will replace the keyCode position on Web applications.

-> INVALID