413875 - '+' and '-' keydown and keyup events have wrong keycodes

Status: RESOLVED FIXED

(Core :: DOM: Events, defect)

Description

[Grant Gayed]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 2.0.50727)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b3pre) Gecko/2008012404 Minefield/3.0b3pre

Pressing '-' or '+' on the main keyboard result in keyup and keydown events whose keycodes are set to the '-' and '+' on the number pad instead.


Reproducible: Always

Steps to Reproduce:
1. go to the provided url
2. press '-' (beside '0' on your keyboard) and note that the keycode values for the keyup and keydown events are 109 (KEYPAD_SUBTRACT), but they should be 189
3. press '+' and note that the keycode values for the keyup and keydown events are 107 (KEYPAD_ADD), but they should be 187

Comment 1

[Grant Gayed]

On the corresponding linux build I see this problem with the '-' key but the '+' key behaves as expected.

Comment 2

[Robert Strong (they/them - no direct email)]

Changing to OS=all due to comment #1

Comment 3

[Nerses Aznauryan]

Hi :)

in FF2 the keycodes looked like this
---------
+ 
keycode=61 
numpad keycode = 107

-
keycode=109
numpad keycode = 109
--------------------------



but in FF3 it looks like this 
---------
+ 
keycode=107 
numpad keycode = 107

-
keycode=109
numpad keycode = 109
--------------------------

I need it to stay as in FF2 because we are writing addon where we should exactly know which key is pressed

Comment 4

[Mike Beltzner [:beltzner, not reading bugmail]]

Karl, can you tell us if this is a big problem?

We're not going to block the ship of Firefox 3.0 on this; if it turns out to be a real problem, please nominate for the 1.9.0.x chain.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

+ and - have traditionally been handled specially in gecko.
But why did we change that? And what caused the regression?
Regression range would be useful.

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/widget/src/windows/nsWindow.cpp&rev=3.745&mark=3041-3045#3039
Something to do with Bug 287179 or Bug 339723?

(Relying on keycodes in web apps or extensions is *very tricky*.
a-zA-Z work pretty well on all browsers and all keyboard layouts, but
almost everything else depends on keyboard layout and language and whatever.
And non of the keyboard handling is specified anywhere.)

Comment 6

[Karl Tomlinson (:karlt)]

(In reply to comment #0)
> 2. press '-' (beside '0' on your keyboard) and note that the keycode values for
> the keyup and keydown events are 109 (KEYPAD_SUBTRACT), but they should be 189

> 3. press '+' and note that the keycode values for the keyup and keydown events
> are 107 (KEYPAD_ADD), but they should be 187

The 187 (0xBB) and 189 (0xBD) codes are not defined here: 

http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/dom/public/idl/events/nsIDOMKeyEvent.idl&rev=1.10&mark=160#157

I assume you are expecting Microsoft virtual key codes

http://msdn.microsoft.com/en-us/library/ms927178.aspx

> On the corresponding linux build I see this problem with the '-' key but the
> '+' key behaves as expected.

I see keycode 61 (0x3d) for =/+ on Linux with US layout. 

What Mozilla should provide (but doesn't and hasn't really in the past
either) is a set of codes that are consistent across platforms.

It seems that many of Mozilla's DOM key codes are based on Microsoft codes but
there have always been some that are not (comment 3).

Comment 7

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

If web developers need to distinguish the '=/+' key and Numpad '0', we need new keycodes for '+' and '-'.

And the consistently between platforms are important. However, the keycode value depends on the platform now. We need to think what is good behavior for web developers.

This cannot be fixed on Gecko1.9.0.x. Therefore, we should document this issue to web developers.

Comment 8

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

And also I think the previous behavior is not good for non-US-keyboad layout that doesn't have '=' on the '+' key. The current behavior is better for now.

Comment 9

[Nerses Aznauryan]

The keyboard layout is not important for keycodes. The keyboard layout affects only to event.charCode and event.which.
keyCode shows which key on the keyboard is pressed. And web developer shօuld be able to distinguish every key on the keyboard.

it looks like in FF2 only keycodes for "-" that cant be distinguished whether it is numpad key or not. But in FF3 its worser "+/=" also can't be distinguished.

Comment 10

[Karl Tomlinson (:karlt)]

(In reply to comment #9)
> The keyboard layout is not important for keycodes.

I wish it were that simple.

The closest thing to documentation on this is:

http://developer.mozilla.org/en/docs/DOM:event.keyCode
"Returns the Unicode value of a non-character key in a keypress event or any key in any other type of keyboard event."

But no one has to spend too much time comparing assignments here with Unicode
to notice that the documentation is very inaccurate.

http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/dom/public/idl/events/nsIDOMKeyEvent.idl&rev=1.10#43

Mozilla's current assignments seem related to virtual key codes in a DOM Level
2 Working Draft,

http://www.w3.org/TR/1999/WD-DOM-Level-2-19990923/events.html#Events-eventgroupings-keyevents

but these were later removed from the spec. 

DOM Level 3 now refers to "key identifiers"

http://www.w3.org/TR/DOM-Level-3-Events/keyset.html#Guide

The examples in the (non-normative) guidelines seem to imply that the
identifiers are for the key (rather the particular character generated by the
combination of key and modifiers), but the identifier is selected based on one
of the characters that can be generated by the key, which will depend on
layout.

--

I haven't seen any clear documentation for this, but the MS virtual key code
VK_OEM_PLUS seems to get assigned to the key on the keyboard layout that has a
plus character, but not if there is a more "important" character on that key
(in which case the virtual key code is based on the other character).  I don't
know what the order of precedence for important characters is.

So the key referred to as VK_OEM_PLUS depends on the layout, and some keyboard
layouts do not have any key called VK_OEM_PLUS.

http://blogs.msdn.com/michkap/archive/2006/04/02/567003.aspx

(In reply to comment #5)
> + and - have traditionally been handled specially in gecko.
> But why did we change that? And what caused the regression?

It changed in attachment 224340 [details] [diff] [review].

The Firefox 2 behavior was to label a VK_OEM_PLUS key with DOM_VK_EQUALS.

That's not so bad for the =/+ key on a US layout, as the keyCode reflects the
character on the key in that situation.

However, sending a DOM_VK_EQUALS just because there is a "+" somewhere on the
key is obviously crazy.

On a Japanese keyboard layout

http://en.wikipedia.org/wiki/Keyboard_layout#Japanese

VK_OEM_PLUS is instead the ;/+ key.  This key is in the same position as the
;/: key on a US layout (and on that layout has the VK_OEM_1 virtual key code).

The change was to label VK_OEM_PLUS with DOM_VK_ADD.

It makes a little more sense to label a key with DOM_VK_ADD because there is a
"+" somewhere on the key.

But choosing a behavior closer the DOM Level 3 guidelines would label
VK_OEM_PLUS with DOM_VK_EQUALS on a US layout (=/+), but DOM_VK_SEMICOLON on a
Japanese layout (;/+).

> (Relying on keycodes in web apps or extensions is *very tricky*.
> a-zA-Z work pretty well on all browsers and all keyboard layouts, but
> almost everything else depends on keyboard layout and language and whatever.
> And non of the keyboard handling is specified anywhere.)

Yes.  With punctuation charCodes in keypress events things are hard enough.
Things get even harder with punctuation and keyCodes given the ability to
select the character from the two or more available is lost.

(In reply to comment #7)
> If web developers need to distinguish the '=/+' key and Numpad '0', we need
> new keycodes for '+' and '-'.

Or perhaps provide something like keyLocation:

http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-KeyboardEvent

Comment 11

[Lee Lofgren]

I am trying to write input validation do disallow various keys using the onkeydown event. I can't tell a + from a =, nor a _ from a - with the code as it currently stands. This bug should be easy to confirm, just use examine the event.charCode or event.which during an onkeydown event. Has this issue been dropped for a reason?

Comment 12

[Lee Lofgren]

It appears that in Firefox 3, up through 3.0.11 on linux, that the + and = sign on the main keyboard section return charCode 61  and the + sign on the numeric keyboard returns 107, the - _ key returns 109 on the main keyboard and the numeric keypad - returns 109 as well, I don't see the - _ as a problem since Shift - can be assumed to be _ on either key. However my Windows Vista 64 with Firefox 3.0.11 returns 107 for the += key on the main keyboard??? I have tried this in safe mode as well to make sure that none of the addons are affecting it.

Comment 13

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #12)
> I don't see the - _ as a problem since
> Shift - can be assumed to be _ on either key.
Really? Not at least on my machine (Finnish keyboard).

Comment 14

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

The keyCode reimplementation at 15, now following keyCode values are used on all of Windows/Linux/Mac.

For printable keys in standard location, the keyCode values are decided from unshifted input character of the key. If it's '-' or '+', then:

'-' key in standard location: DOM_VK_HYPHEN_MINUS (0xAD (173))
'+' key in standard location: DOM_VK_PLUS (0xAB (171))
'-' key in numpad: DOM_VK_SUBTRACT (0x6D (109))
'+' key in numpad: DOM_VK_ADD (0x6B (107))

If '-' or '+' needs Shift key for input, the keyCode values in standard location never used with such keyboard layout.