Closed Bug 833719 Opened 11 years ago Closed 11 years ago

Some function keys are not working since Firefox Version 15

Categories

(Core :: DOM: Events, defect)

x86
Windows XP
defect
Not set
minor

Tracking

()

RESOLVED FIXED
mozilla21
Tracking Status
relnote-firefox --- +

People

(Reporter: h.sammer, Assigned: masayuki)

References

Details

(Keywords: dev-doc-complete, regression)

Attachments

(3 files, 3 obsolete files)

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
Component: Untriaged → Event Handling
Keywords: regression
Product: Firefox → Core
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.
Attachment #705774 - Flags: superreview?(bugs)
Attachment #705774 - Flags: review?(bugs)
Attached patch Part.2 Windows part (obsolete) — Splinter Review
Attachment #705776 - Flags: review?(bugs)
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
Attached patch Part.3 Gtk part (obsolete) — Splinter Review
GTK should set same the new DOM keyCodes if the user uses the IBM 3270 terminal's keys.
Attachment #705777 - Flags: review?(bugs)
Severity: normal → minor
Component: Event Handling → DOM: Events
Version: 18 Branch → Trunk
(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.
Attachment #705774 - Flags: superreview?(bugs)
Attachment #705774 - Flags: superreview+
Attachment #705774 - Flags: review?(bugs)
Attachment #705774 - Flags: review+
Attachment #705776 - Flags: review?(bugs) → review+
Attachment #705777 - Flags: review?(bugs) → review+
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?
Flags: needinfo?(h.sammer)
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.
Flags: needinfo?(h.sammer)
(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.
Assignee: nobody → masayuki
Attachment #705774 - Attachment is obsolete: true
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #710171 - Flags: superreview?(bugs)
Attachment #710171 - Flags: review?(bugs)
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.
Attachment #705776 - Attachment is obsolete: true
Attachment #710172 - Flags: review?(jmathies)
Attachment #710172 - Flags: review?(bugs)
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.
Attachment #705777 - Attachment is obsolete: true
Attachment #710175 - Flags: review?(karlt)
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.
Attachment #710172 - Flags: review?(jmathies) → review+
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.
Attachment #710175 - Flags: review?(karlt) → review+
(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.
Attachment #710171 - Flags: superreview?(bugs)
Attachment #710171 - Flags: superreview+
Attachment #710171 - Flags: review?(bugs)
Attachment #710171 - Flags: review+
Attachment #710172 - Flags: review?(bugs) → review+
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)
(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?
You need to log in before you can comment on or make changes to this bug.