153344 - mozilla maps many keys to NS_VK_SUBTRACT

Status: NEW

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Kyle Yuan]

1. Windows, Numpad '-'(code 109) and '-' near the backspace (code 189);
http://lxr.mozilla.org/seamonkey/source/widget/src/windows/nsWindow.cpp#2613

2. GTK, GDK_minus, GDK_KP_Subtract and GDK_underscore
http://lxr.mozilla.org/seamonkey/source/widget/src/gtk/nsGtkEventHandler.cpp#168
http://lxr.mozilla.org/seamonkey/source/widget/src/gtk/nsGtkEventHandler.cpp#185
http://lxr.mozilla.org/seamonkey/source/widget/src/gtk/nsGtkEventHandler.cpp#209

In event handler, we can't distinguish which key was pressed.

Comment 1

[Mike Kaply [:mkaply]]

Those keys have different keycodes.

Yes, if you are looking at just the charcode, you can't tell (and you shouldn't 
be able to)

charcode is what character the key produces. If I have three keys on my keyboard 
that produce a "-" sign, they all will map to the same charcode.

However, they should all have different keycodes.

GTK mapping underscore to "-" is probably just wrong.

Comment 2

[Kyle Yuan]

sorry, the link is obsolete. the following is the code in 
widget\src\windows\nsWindow.cpp:

UINT nsWindow::MapFromNativeToDOM(UINT aNativeKeyCode)
{
  switch (aNativeKeyCode) {
    case 0xBA: return NS_VK_SEMICOLON;
    case 0xBB: return NS_VK_EQUALS;
    case 0xBD: return NS_VK_SUBTRACT; //=109, that is keyCode of Numpad "-"
  }

  return aNativeKeyCode;
}

BOOL nsWindow::OnKeyDown( UINT aVirtualKeyCode, UINT aScanCode, LPARAM aKeyData)
{
  WORD asciiKey;
  asciiKey = 0;
  aVirtualKeyCode = !mIMEIsComposing?MapFromNativeToDOM
(aVirtualKeyCode):aVirtualKeyCode;
  BOOL result = DispatchKeyEvent(NS_KEY_DOWN, asciiKey, aVirtualKeyCode, 
aKeyData);
  ...
}

PRBool nsWindow::DispatchKeyEvent(PRUint32 aEventType, WORD aCharCode, UINT 
aVirtualCharCode, LPARAM aKeyData)
{
  ...
  event.charCode = aCharCode;
  event.keyCode  = aVirtualCharCode;
  ...
}  

You can see, both charCode and keyCode are same.

Comment 3

[Akkana Peck]

The issue here is that nsIDOMKeyEvent.idl doesn't give us symbols for underscore
or for non-keypad dash (or for lots of other punctuation).  Joki?  You said a
couple of years ago that the W3C was working on a standard that would solve this
problem (and lots of other related ones) for us.  What's the latest story?

Comment 4

[[e-mail]]

Perhaps an event needs a new modifier isNumKeyPad or something? Although the
seemingly simple change of enabling the shift modifier for the space key
prevented shift+space from working in text fields.

Also I don't see the point of MapFromNativeToDOM because the key codes aren't
directly related to the char codes e.g. on my keyboard I have a key that
produces the # char but on a US keyboard it's shift+3 so there is no key code for #.

Comment 5

[Pham]

.

Comment 6

[Les Barstow]

This also happens for KP+ vs =+ (Windows XP 32-bit, Firefox 3.6.12), and I'm going to have to tell one of our application users that they can't remap the KP+ key to a tab key like they're used to doing for data entry.

IMHO this is an important and seemingly pointless (i.e. why is it even occurring) bug.  I know PC keycodes aren't the easiest thing in the world, but that's no reason to improperly set the keycode for the =+ key from its proper value (61) to the value assigned to KP+ (107).  How is an application even supposed to figure out if you mean "=" or "+" in that situation?

Comment 7

[Les Barstow]

Just as an aside - still not fixed in Firefox 4.0b7.

Because I wasn't terribly obvious in my previous comment: if KP-Plus and Equal-Plus are both the same keycode, then, unshifted, one generates '=' and one generates '+' - mutually conflicting values!  Firefox surely doesn't have this conflict internally, or we would never be able to type an '='...

Older versions of Firefox apparently used 61 for the =+ key; IE uses 187.  (187, incidentally, would be in line with related symbol-only keys; so would using 189 instead of 109 for the -_ key.)