880971 - Keys with modifiers works only on simplest Windows’ keyboard layouts

Reporter

Description

•

11 years ago

I extensively tested many keyboard layouts, and found my way through the event handling C++ code. Now I can match most problems to particular pieces of buggy logic in the input handling code, and I think that I know simple workarounds. The initial indications of the problems which led me to this whole investigation are listed on http://search.cpan.org/~ilyaz/UI-KeyboardLayout-0.14/lib/UI/KeyboardLayout.pm#Firefox_misinterprets_keypresses. Now, when I read the source code, I found many more problems.

The key reason for the problems is: one should not have used the advice from http://blogs.msdn.com/b/michkap/archive/2005/01/19/355870.aspx to implement keyboard input handling. There are easier solutions which actually work (in contrast to the current approach, which is complicated, and works only time to time).

But now, when this approach is implemented, not everything is lost: one may need to ignore most information gathered with the current logic, but the rest of the code is in pretty good shape — only minor changes are needed to make it run. The major problem with this bug report is that it is my first for Mozilla, I do not know the protocols, and I need to indicate a few dozens of pieces of buggy code, match them to detectable bugs, and describe workarounds.

The situation is complicated by the fact that apparently, the current logic is build upon a wrong understanding of Windows’ keyboard input architecture. So let me start here with the description of the architecture. (Most of this is documented, some is deduced from experiments; all I write below is experimentally checked.)

—————————————————————————————————————————————————————————————————————————————
A) A keyboard driver is just a static table describing what to do with keypresses; the table is packed into a DLL.

A') There is no way to query this table less than in 2²⁶⁴ system calls.

B) The keyboard subsystem remembers 16 bits of state (the “dead key”), extra 3 bits for flip-state of VK_CAPITAL/VK_KANA/VK_NUMLOCK, and has 6 bits of context for each keypress. Theoretically, with these 6+3 bits of context+flipState, one can define 66 characters per keypress (but apparently, some of these 66 choices are reserved — I experimented with about 20 of them, and 1 of 20 does not work; so it is at most 65). (Why 66? With CapsLock on, only one bit is handled; with CapsLock off, there are 6bit. Roughly speaking…)

B') There is no way to query the 16-bit state of deadKey, and the 6 bits of context.

B") The 6 bits of context are calculated based on bitmap of currently pressed 256 keys by ORing 6-bit mask associated with every virtual key by the keyboard driver. One cannot query these masks. (On the other hand, one cannot calculate the context, but one memorize this state by storing the whole 256bit mask.)

C) The application can query which character is produced by pressing a given key in the context of the given 256-bit mask. However, such querying CHANGES THE STATE. (Well, everybody knows this — it is what is described in the MicroSoft link above.)

D) The keyboard subsystem is doing some processing in addition to what is described in the driver, but it is mostly harmless for the questions I discuss (I know about handling of AltGr-NUMBER input of Unicode, some bruhaha with different VK delivered on C-Break [and NumLock/Shift on keypad keys], and some default mappings from scancode to VK on exotic keys not defined in the drivers). I will ignore this part in what follows (it happens on KeyUp).

E) There are some additional ramifications for FarEastern keyboards, but I cannot find any documentation, and do not have context to do experiments.
———————————————————————————————————————————————————————————————————————————
That’s it. (Well, one can also mention that the state is PER-DRIVER; if several drivers are active on the system, each keeps a separate state. But the state is shared by all the windows/threads using THE SAME driver. As one can imagine, this may lead to nice scenarios if user switches windows in a middle of a deadkey sequence…)

=================== SUMMARY

One cannot (easily) deduce which character is going to be produced by the keydown without examining the following WM_CHAR message. But nsWindow::OnKeyDown() is, in many cases, examines the WM_CHAR(s), then throws away the results and substitutes some guesses instead.

(It was in http://mxr.mozilla.org/mozilla-central/source/widget/windows/nsWindow.cpp#6462, but now I see I need to reexamine the sources.) In short: instead of throwing away the information completely, one should only do it WHEN NEEDED: for control chars (and 0x7F), 0x20 (delivered by C-Space), and, possibly, for undefined deadKey sequences. (But I think throwing away undefined deadKey sequences is a bad UI. But this is a topic for separate discussion.)

Now when the code has changed, I need to reexamine it; sigh… Anyway, I suspect that the state of mind which lead to throughing away WM_CHAR messages is not applicable nowadays: I think it was to deliver the charCode on keyDown; but doing experiments with https://bug50255.bugzilla.mozilla.org/attachment.cgi?id=55849&action=view, I see that charCode is no longer delivered! I must go now; when I reexamine the new code, I will comment more.