User Agent: Mozilla/5.0 (Windows NT 5.1; rv:18.0) Gecko/20100101 Firefox/18.0 Build ID: 20130116073211 Steps to reproduce: We are using a Fujitsu trimodal keyboard with additional function keys F13 – F22. Everything worked fine until Firefox Version 14. Actual results: Since Version 15 until now with Firefox Version 18.1 the keys F13-F14, F16- F17, F19-F20 are returning key code 0, F15 now is returning key code 0x06, F18 is returning 0x82 (OK). Other browsers like Internet Explorer or Google Chrome always return the correct values: F13=0xF5, F14=0xF3, F15=0x2F, F16=0xFB, F17=0xF9, F18=0x82 (OK), F19=0xFF, F20=0xFF. Perhaps the problem is similar to: http://support.mozilla.org/de/questions/936098#answer-385128 Expected results: Firefox should return the correct key codes like it did until Version 14.

Would it be possible for you to find a regression range with our semi-automatic tool ? It could be difficult for our developer without the hardware. The tool with instructions can be found here: http://mozilla.github.com/mozregression/ Example usage: mozregression --good=2012-08-01

I don't recall changes to function keys. Masayuki?

It's odd. We support F13 (0x7C) - F24 (0x87) but the values are not 0xF*. We were passing through the native virtual keycode value as DOM keyCode. http://msdn.microsoft.com/en-us/library/dd375731%28v=VS.85%29.aspx http://mxr.mozilla.org/mozilla-central/source/dom/interfaces/events/nsIDOMKeyEvent.idl#133 And even now, we handle them: http://mxr.mozilla.org/mozilla-central/source/widget/windows/KeyboardLayout.cpp#1085 So, sounds like your keyboard driver or utility doesn't send correct virtual keycode for the physical F13-F24 keys. F15 probably sends VK_HELP which was used in NumPad of NEC PC9821 series (not PC/AT compatible machine). IE probably passes through the native virtual keycode to DOM keycode. Therefore, the keys use legacy keyCodes which were used on non-PC environment (see the key name of the MSDN's document of the 0xF*). So, the main problem of this bug is, the keyboard driver or utility's problem. So, this is not our fault. Please check the KeyboardEvent.key value on IE9 or IE10, then, you must see unexpected key names. I.e., the values must not be "F*". https://developer.mozilla.org/en-US/docs/DOM/KeyboardEvent#Key_names_and_Char_values I don't think we should add such legacy keyCode support anymore. We should only support them with .key in the future.

Sorry about the misunderstanding. The buttons show F13 – F20. If I compare it against http://msdn.microsoft.com/en-us/library/dd375731%28v=VS.85%29.aspx (1) http://mxr.mozilla.org/mozilla-central/source/widget/windows/KeyboardLayout.cpp#1085 (2) https://developer.mozilla.org/en-US/docs/DOM/KeyboardEvent#Key_names_and_Char_values (3) then I found in the documentation: Button expected (1) (2) (3) key code F13 0xF5 OEM specific F14 0xF3 OEM specific F15 0x2F VK_HELP VK_HELP VK_HELP F16 0xFB VK_ZOOM VK_ZOOM VK_ZOOM F17 0xF9 VK_EREOF VK_EREOF VK_EREOF F18 0x82 (OK) VK_F19 VK_F19 VK_F19 F19 0xFF F20 0xFF Furthermore, everything worked fine until Firefox Version 14 and the keyboard driver hasn't changed. Also Google Chrome has no problems and switching back to Firefox Version 14 everything worked. IE8, IE9, IE10, Chrome and Firefox until Version 14 return the expected key codes.

Because you test only on Windows, you can think so (i.e., passing through the native virtual keycode to DOM keyCode is good). However, it caused incompatibility with other platform's Gecko. In the cycle of Firefox 15, we sorted out the keyCode table on all tier-1 platforms. We don't hope to add new keyCode anymore because the keyCode compatibility isn't perfect and it's deprecated in D3E. All browsers should support .key attribute and such legacy keys should be supported by the new attribute. So, I believe that this bug should be marked as INVA.

Not sure. Can we test what keycodes are reported in other platforms? Also, returning keyCode 0 is just odd.

If the keyboard driver using VK_F13-F22 correctly, we can set same DOM F* keyCode. # On Windows, keyboard driver maps scan code to virtual keycode.

We use <= 0xE1 for DOM keyCode. So, we *can* support 0xF* if we add new DOM keyCode consts. Do you want that?

I think we should try to be as compatible with other browsers as possible.

VK_ATTN (0xF6) VK_CRSEL (0xF7) VK_EXSEL (0xF8) VK_EREOF (0xF9) VK_PLAY (0xFA) VK_ZOOM (0xFB) VK_OEM_CLEAR (0xFE) Only these keys are defined their key names in D3E draft. So, it might be worthwhile to support only them. Other unnamed virtual keycodes shouldn't be useful.

And I guess that the reporter's trouble is about only VK_ZOOM case, isn't it? If so, we can do: 1. nothing 2. support the keys in comment 10 3. only support VK_ZOOM

FYI: Function of OEM specific keys depend on the hardware vender. http://msdn.microsoft.com/en-us/library/aa452679.aspx So, it doesn't make sense we set them to DOM keyCode such as 0xF5 and 0xF3.

Hmm. Why not? If the keycode is something totally non-standard then report it as-is? It may not work consistently across the OSes and devices, but at least the event had some data.

OEM specific virtual keycodes might be used for printable keys. So, if they pass through to DOM keyCode, we need to care same keyboard layout's same key on other platforms. But the investigation cost is very expensive. Therefore, I believe that we should add to support only non-printable virtual keycode having name. Please note that this is very edge case. Most keyboards for Windows in the world don't have F13-F24. And even if some keyboards have them, their custom keyboard driver should use VK_F13 - VK_F24 or the keyboards should use scan codes which will be mapped to VK_F13 -VK_F24 by standard keyboard drivers. However, this case is, there are physical F13-F20 keys, but they don't use proper scan code and the existence is not expected by the keyboard driver. Actually, F19 and F20 have same virtual keycode 0xFF which are not named. So, they must not work on any apps. I don't find the product page of "Fujitsu trimodal keyboard", then, I guess that (1) the keyboard isn't designed for Windows, it's designed for non-PC hardware or Linux (or UNIX based OS), or (2) it's designed for Windows but the reporter hasn't installed custom keyboard driver for it. I strongly recommend that we should chose an approach from the list in comment 11.

Approach (2) then? But would be still good to check how other browsers handle this situation.

I believe that we shouldn't support OEM specific keys (0xE3-E4, 0xE6, 0xE9-F5) and unnamed virtual keycodes. I think that those new keyCode support is safe and make better compatibility.

Some additional information: The keyboard is designed for Windows. In the moment we are using it with Windows XP and Windows 7. We haven't installed any custom keyboard driver. Scan codes: Button scan code expected key code F13 0x5E 0xF5 F14 0x5F 0xF3 F15 0x63 0x2F VK_HELP F16 0x62 0xFB VK_ZOOM F17 0x5D 0xF9 VK_EREOF F18 0x6A 0x82 (OK) VK_F19 F19 0x74 0xFF F20 0x77 0xFF

GTK should set same the new DOM keyCodes if the user uses the IBM 3270 terminal's keys.

(In reply to Olli Pettay [:smaug] from comment #15) > Approach (2) then? But would be still good to check how other browsers > handle this situation. What situation did you mean? IE and Chrome on Windows make the virtual keycodes pass through DOM keyCode without any change. On GTK, we can support the 3270 terminal keys (part.3), but I'm not sure what keyCode is set on Chrome for Linux. I don't know how to test that.

Additional information: The customer uses this keyboard for a 9750 (= BS2000 mainframe from Fujitsu) terminal emulation. The mainframe and the keyboard are widely used in Europe. The customer reporting the keyboard problem is a very big insurance company in Germany. They switched from IE to FF due to the much better performance. So we would very appreciate to have a solution for this problem.

Reporter, does https://bug833719.bugzilla.mozilla.org/attachment.cgi?id=705774 contain all the codes you need?

Comment on attachment 705777 [details] [diff] [review] Part.3 Gtk part Masayuki, I don't know what to do with those XXXs. Perhaps ask karlt?

(In reply to Olli Pettay [:smaug] from comment #22) > Reporter, does > https://bug833719.bugzilla.mozilla.org/attachment.cgi?id=705774 contain all > the > codes you need? I don't include 0xF3, 0xF5 and 0xFF intentionally. 0xF3 and 0xF5 are OEM specific keys. 0xFF is invalid virtual keycode on Windows (actually, F19 and F20 of the reporter's keyboard share this).

(In reply to Olli Pettay [:smaug] from comment #23) > Comment on attachment 705777 [details] [diff] [review] > Part.3 Gtk part > > Masayuki, I don't know what to do with those XXXs. Perhaps ask > karlt? Yeah, after reporter's feedback.

(In reply to h.sammer from comment #21) > Additional information: The customer uses this keyboard for a 9750 (= BS2000 > mainframe from Fujitsu) terminal emulation. The mainframe and the keyboard > are widely used in Europe. > > The customer reporting the keyboard problem is a very big insurance company > in Germany. They switched from IE to FF due to the much better performance. Then, why are these strange mapped keys necessary on *Web* browsers?

Our company provides a Browser solution for terminal emulations for IBM 3270/5250, Fujitsu 9750/97801 and Unix VT. Especially the 9750 Terminal uses many F-Keys to map terminal functions. To get an idea please have a look at http://www.logics.de/ajax/login/index.jsp?_StartLink=*9750-offline.ini This is a 9750 terminal session managed by our LogWeb/Ajax Client. I'll come back soon with the keycode list.

Here is the list of the key codes: scan code expected button Firefox virtual key returns 73 0xC1 insert line 6F 0xED delete character 79 0xFF delete line 78 0xFF HELP 75 0xFF START 71 0xE9 NUM block "=" 5C 0xEA NUM block "CE" 5E 0xF5 F13 5F 0xF3 F14 63 0x2F F15 0x06 62 0xFB F16 5D 0xF9 F17 74 0xFF F19 77 0xFF F20

First, I still don't like to support OEM specific keys since I believe that these keys SHOULD NOT work on web applications in any situations. But I really want to know which keys are actually used on your system. (In reply to h.sammer from comment #28) > Here is the list of the key codes: > scan code expected button Firefox > virtual key returns > 73 0xC1 insert line 0xC1 is reserved by Windows. It MUST NOT be used by any keyboard drivers, though. > 6F 0xED delete character 0xED is OEM specific. The name is only defined as VK_OEM_PA3 for Nokia/Ericsson (for WinCE?) Fortunately, we've never used this code. It's possible to define a DOM keyCode for this. > 79 0xFF delete line > 78 0xFF HELP > 75 0xFF START > 74 0xFF F19 > 77 0xFF F20 0xFF are not defined by Windows. And it does not make sense these keys share only one virtual keycode. Therefore, I guess that these keys are not used on Web applications, right? It's impossible to distinguish the keys in Web application level. These keys should be available only on native applications because native applications can handle scan code directly. > 71 0xE9 NUM block "=" > 5C 0xEA NUM block "CE" > 5E 0xF5 F13 > 5F 0xF3 F14 They are also OEM specific keys. These keys are defined as: 0xE9: VK_OEM_RESET 0xEA: VK_OEM_JUMP 0xF3: VK_OEM_AUTO 0xF5: VK_OEM_BACKTAB all of them are defined for Sony/Ericsson. However, AFAIK, VK_OEM_AUTO is also used on JIS keyboard layout for Japanese IME special key. So, if we support these OEM specific keys, these key events never indicate a specific key (i.e., only supported on Windows). > 62 0xFB F16 > 5D 0xF9 F17 These are supported in the patch.

Reporter: My question is, do you need all keycode support all of them? I.e., actually being handled in your applications?

If we will make all OEM keycodes pass through to DOM keyCode, unfortunately, 0xE1 is already defined as DOM_VK_ALTGR. However, it's the latest added keyCode and only available on Gecko on GTK. So, I guess that no application actually handles it. If would support all of them, we should assign another value for DOM_VK_ALTGR.

We don’t use 0xE1. In the moment we use the keycodes mentioned in comment 28. We think, it’s a good idea to pass all OEM keycodes through to DOM keyCode. Then the behaviour is compatible to other browsers. If there is a patched version of Firefox available we would be happy to test it and to tell good news to our customer.

(In reply to h.sammer from comment #32) > We don’t use 0xE1. In the moment we use the keycodes mentioned in comment 28. > We think, it’s a good idea to pass all OEM keycodes through to DOM keyCode. > Then the behaviour is compatible to other browsers. > If there is a patched version of Firefox available we would be happy to test > it and to tell good news to our customer. Okay, so, how about 0xC1 and 0xFF? They must not be used by any keyboard drivers/utilities because Windows does NOT define the name of them. Even if we support OEM specific virtual keycodes, I don't want to support these two codes because we cannot guess the future of these values on Windows platform. So, these two key support may be risky.

We don’t know which buttons the customer will use in the future. He decided to buy this keyboard because the users are familiar with several legacy applications, which use many function keys. This applications are now running in an emulation (AJAX) in the browser. We think, that every particular button should return a specific keycode. Unfortunately a few buttons produce the same code 0xFF with some browsers, but we would prefer different codes. If we know what we get if a button is pressed we can handle it.

(In reply to h.sammer from comment #34) > Unfortunately a few buttons produce the same code 0xFF with some browsers, > but we would prefer different codes. The reason is, every web browser on Windows handles virtual keycode of WM_KEYDOWN. This is usual manner of Windows application. Virtual keycode values are converted by keyboard layout and driver from USB's code. So, if keyboard has special keys, the vender should provide custom keyboard driver. So, you should claim to the vender rather than software venders about some keys sharing same virtual keycode. Okay, I'll attach new patches which supports all OEM specific virtual keycodes on Windows. However, it won't support unnamed keycodes for risk management with other platform's behavior. So, 0xC1 and 0xFF are never set to KeyboardEvent.keyCode.

Let's support all OEM specific virtual keycodes too, but except some keycodes which we already defined, such as 0xE1. And I name them DOM_VK_WIN_*. The name makes the meaning clearer.

OEM specific virtual keycodes should pass through DOM keyCode. We shouldn't support 0xE1. We already use it as AltGr key on Linux. And the virtual keycode was used only on PC-9821 series. http://msdn.microsoft.com/en-us/library/aa452679.aspx Starting WinXP, Microsoft stopped supporting PC-9821 series. So, ignoring 0xE1 must not be problem. # Caring the 0xE1, 0xE3 and 0xE4 as OEM key (not OEM specific key) was my mistake.

The new DOM keyCode except defined for OEM specific keys on Windows should be mapped on GTK too. Although, I don't find ZOOM keysym.

Note that 0xC1 and 0xFF won't be supported by the patches since these keys are undefined on Windows SDK. So, using the virtual keycodes is really the keyboard driver or utilities fault.

The interface of the keyboard is PS/2 (not USB). With the standard driver we get different scan codes for every button. If you deliver other keycodes (not 0xC1 and 0xFF) it would be OK for us.

(In reply to h.sammer from comment #41) > If you deliver other keycodes > (not 0xC1 and 0xFF) it would be OK for us. I believe we should not do so. If Windows will assign a meaning to them, we need to send same keyCode for same meaning key on all other platforms. At that time, if other DOM keyCode would be already used for it on other platforms, we need to change the keyCode mapping on Windows again. It's too bad thing.

FYI: Even after we implement KeyboardEvent.key, 0xC1 and 0xFF are mapped to "Unidentified" since Windows SDK doesn't define any meaning for them. So, they must not be available on web browsers.

Comment on attachment 710175 [details] [diff] [review] part.3 New DOM keyCodes except OEM specific keys should be mapped on Linux (r=smaug) I don't know how to map a single zoom key to GDK_KEY_ZoomIn and GDK_KEY_ZoomOut, so leaving the mapping empty for now seems sensible. XF86XK_AudioPlay may be more appropriate for VK_PLAY. At least there are some keyboards mappings that generate that KeySym. I don't see any 3270 KeySyms on xkb symbol mappings for any keyboards.

(In reply to Karl Tomlinson (:karlt) from comment #44) > XF86XK_AudioPlay may be more appropriate for VK_PLAY. That is GDK_KEY_AudioPlay in GDK terms.

(In reply to Karl Tomlinson (:karlt) from comment #44) > Comment on attachment 710175 [details] [diff] [review] > part.3 New DOM keyCodes except OEM specific keys should be mapped on Linux > (r=smaug) > > I don't know how to map a single zoom key to GDK_KEY_ZoomIn and > GDK_KEY_ZoomOut, so leaving the mapping empty for now seems sensible. Yeah, I think that it's enough to support them at implementing KeyboardEvent.key attribute. > XF86XK_AudioPlay may be more appropriate for VK_PLAY. At least there are > some keyboards mappings that generate that KeySym. I don't see any 3270 > KeySyms on xkb symbol mappings for any keyboards. VK_PLAY isn't for a virtual keycode for media. For that, there is VK_MEDIA_PLAY_PAUSE. We should support it at implementing KeyboardEvent.key. http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#key-values-list GDK_3270_Play should be 'Play'. GDK_KEY_AudioPlay should be 'MediaPlay' in the D3E key name list.

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #46) > GDK_3270_Play should be 'Play'. GDK_KEY_AudioPlay should be 'MediaPlay' in > the D3E key name list. Sounds good. Thanks for explaining that.

https://hg.mozilla.org/integration/mozilla-inbound/rev/0253d6c5a552 https://hg.mozilla.org/integration/mozilla-inbound/rev/122afc7bf2e5 https://hg.mozilla.org/integration/mozilla-inbound/rev/f7de926acf42 0xC1 and 0xFF are not added since they are invalid virtual keycode on Windows (we cannot give proper names to them, and they're not useful for most web applications all over the world).

As already mentioned in comment 41 we can handle every keycode delivered by Firefox. It is not necessary that Firefox returns 0xC1 or 0xFF. scan code Firefox 14 Firefox 18 button returned returns (keyboard) 73 0xC1 nothing insert line 79 0xFF nothing delete line 78 0xFF nothing HELP 75 0xFF nothing START 71 0xE9 nothing NUM block "=" 5C 0xEA nothing NUM block "CE" 5E 0xF5 nothing F13 5F 0xF3 nothing F14 63 0x2F 0x06 F15 62 0xFB nothing F16 5D 0xF9 nothing F17 74 0xFF nothing F19 77 0xFF nothing F20 For the scan codes 0x73, 0x74, 0x75, 0x77, 0x78 and 0x79 we can handle every distinct keycode delivered by Firefox.

Reporter, could you test the next nightly builds (or perhaps the ones after that), http://nightly.mozilla.org/ .

(In reply to Olli Pettay [:smaug] from comment #50) > Reporter, could you test the next nightly builds (or perhaps the ones after > that), http://nightly.mozilla.org/ . Of course, should I download from "Windows (Express)" or "Windows (Standard)"? How should I proceed?

Same as usual Windows application, we don't handle scan code directly since scan code values don't have any meaning but DOM keyCode has been defined with virtual keycode. Keyboard drivers give the meaning by mapping them to virtual keycode. So, the 0xC1 and 0xFF issue is not ours (and also not usual Windows applications'). In other words, you need to provide better keyboard driver for your customers if you need to solve the issue on your application. This code let you know which virtual keycode values will be supported on Fx21: https://hg.mozilla.org/integration/mozilla-inbound/diff/f7de926acf42/dom/interfaces/events/nsIDOMKeyEvent.idl The patches get back some virtual keycode values for legacy hardware and most OEM specific key. I believe that this is the best practice for usual users and developers. Please note that the 0xC1 and 0xFF issue is really an irregular case. We shouldn't own any risk for such cases. I understand your dissatisfaction about this issue if you want 0xC1 and 0xFF actually. But I believe it's out of scope of usual Windows application.

(In reply to h.sammer from comment #51) > Of course, should I download from "Windows (Express)" or "Windows > (Standard)"? > How should I proceed? I'd use the Standard one. But wait for a day or so to ensure the patch gets into the Nightly build. Or you can download Nightly now, and update it tomorrow (help->about->check for updates)

https://hg.mozilla.org/mozilla-central/rev/f7de926acf42 https://hg.mozilla.org/mozilla-central/rev/122afc7bf2e5 https://hg.mozilla.org/mozilla-central/rev/0253d6c5a552

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #29) [Sorry for lateness, just saw this through v21.0 announcement] > 0xC1 is reserved by Windows. It MUST NOT be used by any keyboard drivers, though. What made you think so? Are you just reading winuser.h? The comments in header files are not a reliable indication of anything; I presume this sentence is stuck there from mid-80s… Virtual key codes 0xC1 and 0xC2 are in very wide usage (back of envelop calculation: I presume about 3% of keyboards produce 0xC1, 100(s?) of millions). Scan kbd.h for ABNT_C1 and ABNT_C2, and/or decompile (in MSKLC) the Portugese ABNT/ABNT2 keyboards. 73 ABNT_C1 0 002f 003f -1 00b0 // SOLIDUS, QUESTION MARK, <none>, DEGREE SIGN 7e ABNT_C2 0 002e 002e -1 -1 // FULL STOP, FULL STOP, <none>, <none> (See also http://en.wikipedia.org/wiki/Portuguese_keyboard_layout.) Position of these is documented more on http://www.win.tue.nl/~aeb/linux/kbd/scancodes-5.html (in 5.12, and diagrams referenced from there).

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #55) > https://developer.mozilla.org/en-US/docs/DOM/KeyboardEvent#Virtual_key_codes About 1–2 screenfulls up, there is this: =================================================== quote This is usually the decimal ASCII ( web.link("http://tools.ietf.org/html/" + $0, "RFC " + $0) ) =================================================== end Is it as intended?

Checking this problem report, I read through http://mxr.mozilla.org/mozilla-central/source/widget/windows/KeyboardLayout.cpp. Now I think I may identify at least one half of the problems described on http://search.cpan.org/~ilyaz/UI-KeyboardLayout-0.14/lib/UI/KeyboardLayout.pm#Firefox_misinterprets_keypresses. What is the best way to report multiple problem (on the scale: from small buglets to a sillyiness of the general architecture)?

(In reply to Ilya Zakharevich from comment #58) > What is the best way to report > multiple problem (on the scale: from small buglets to a sillyiness of the > general architecture)? Please file a new bug report and mark it as blocking this report. If the bugs are closely related, then one bug report is sufficient. If there are different issues involved, then separate reports are better.

(In reply to Karl Tomlinson (:karlt) from comment #59) > Please file a new bug report and mark it as blocking this report. First of all, I do not know the exact meaning of “blocking” for mozilla development, but I think that the bugs I see are not intertwined with the bug discussed on this page. On the other hand, the mentioned in #57 issues ARE immediately related, and are IMO much more important than what is discussed as “fixed” here. Do I need to go through the “blocking” routine for the problems of #57?

(In reply to Ilya Zakharevich from comment #56) > > 0xC1 is reserved by Windows. It MUST NOT be used by any keyboard drivers, though. > > What made you think so? Are you just reading winuser.h? I see in https://bugzilla.mozilla.org/show_bug.cgi?id=865566 that you have already discovered C1 and C2! Great! I just wanted to mention #865566 here since it is so closely related… > 73 ABNT_C1 0 002f 003f -1 00b0 // SOLIDUS, QUESTION MARK, <none>, DEGREE > SIGN > 7e ABNT_C2 0 002e 002e -1 -1 // FULL STOP, FULL STOP, <none>, <none>

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) (Offline 5/28 - 6/1) from comment #55) > https://developer.mozilla.org/en-US/docs/DOM/KeyboardEvent#Virtual_key_codes Is it possible to beef up https://bug50255.bugzilla.mozilla.org/attachment.cgi?id=55849&action=view and reference it from this document, near where the fields are defined?