User Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20100101 Firefox/15.0 Build ID: 20120824154833 Steps to reproduce: I updated to Firefox v15. I've done the following a hundred times before the update with no problem: I visited my own Synology DiskStation server with DSM 4.0 and tried to log into the web- and AJAX-based shell ("Shellinabox") for the DiskStation's linux OS. Actual results: For both username and password, The following characters were not displayed/registered by the shell anymore (separated by semicolons): +;*;~;-;_;ß;?;\ If I press "´" (accent) before, the characters display fine and are registered. Expected results: I should've been able to enter any special character without first hitting "`".

you can reproduce the bug described above by going to http://code.google.com/p/shellinabox/ and entering e.g. a "+" (without quotes).

I was using a german keyboard layout on my laptop. Although I don't think this has anything to do - take that into account if you can't reproduce this. When I swith num-lock on, e.g. the plus sign can be entered normally (with the applicable "+" key which is active for the num-lock).

Regression window(m-i) Good: http://hg.mozilla.org/mozilla-central/rev/f2b2b99108a2 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120517030029 Bad: http://hg.mozilla.org/mozilla-central/rev/895e12563245 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120517110214 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f2b2b99108a2&tochange=895e12563245 Regression window(m-i) Good: http://hg.mozilla.org/integration/mozilla-inbound/rev/2c3647738e81 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120516230826 Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/12f13acb5ea8 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120517005526 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=2c3647738e81&tochange=12f13acb5ea8 Suspected : Bug 630810

I just re-installed FF 14, everything works fine. So it really seems to be a FF 15 issue.

Starting Firefox 15, some keyCode values have been changed on probably all keyboard layouts. According to the Demo, vt100.js listens both keydown and keypress events and when they think they cannot know which character will be inputted by following keypress event, they're using keypress event's charCode. Using charCode of keypress is the right way to know which character is inputted. So, they shouldn't use keydown event for the purpose at least on Gecko. If they stop to set normalKey true in keyDown() for printable keys, the vt100.js should work fine. Anyway, I think that the code works on Gecko differently between platforms if keyboard layout isn't ASCII capable. Only on Windows, probably, users can input ASCII alphabets even with non-ASCII capable keyboard layouts such as Arabic or Cyrillic but it's not so on other platforms (older Gecko for non-Windows always set 0 for Unicode character input key). The series of bugs for keyCode reimplementation fixed such inconsistent behavior. See also: https://developer.mozilla.org/en-US/docs/DOM/KeyboardEvent#Virtual_key_codes

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #5) > Starting Firefox 15, some keyCode values have been changed on probably all > keyboard layouts. > > Anyway, I think that the code works on Gecko differently between platforms > if keyboard layout isn't ASCII capable. Only on Windows, probably, users can > input ASCII alphabets even with non-ASCII capable keyboard layouts such as > Arabic or Cyrillic but it's not so on other platforms (older Gecko for > non-Windows always set 0 for Unicode character input key). > > See also: > https://developer.mozilla.org/en-US/docs/DOM/KeyboardEvent#Virtual_key_codes I do not understand the above. First, a german keyboard is ASCII-capable. Second, I tried to enter a "?" (question mark) on my german keyboard, which is clearly a standard printable character.

Please read the document in MDN, first. The '?' key caused DOM_VK_OPEN_BRACKET which is same as VK_OEM_4. This behavior was unexpected. The keyCode means [/{ key on US keyboard layout. It shouldn't be used for '?' key on German keyboard layout. So, web developers had needed to know the current keyboard layout if they want to convert from keyCode to inputting charCode. However, it's impossible because there is no such API. The new rules decide keycode from the actual input character by the key. By the new rules, the '?' key of German keyboard layout causes DOM_VK_QUESTION_MARK which has been available since Fx15. (So, I guess that the script is confused by the unknown (new) keyCode value.) Anyway, web applications should use keypress event and its charCode for checking inputting character for a11y. And if your report is actually our bug, I'll reopen this bug. You don't need to change the bug status. Please post only your comment and keep the status.

FYI: The '?' key on German keyboard layout caused 0 for keyCode before Fx14 on Mac and Linux. However, it's now causes DOM_VK_QUESTION_MARK on all of Windows, Mac and Linux. This is what we needed to change the rules.