KeyHell

First a real life example that indicates the nature of some of these problems:

If you have a Greek keyboard layout then one key would normally represent the letter "phi".

In Firefox 2 on Windows and Linux, if you pressed the Alt key together with phi, then the charCode in the event was still phi. (Mac doesn't really have an Alt key though some people would like to think so.)

During Firefox 3 development a greater proportion of users used US builds, and so those people felt that, when the phi key was used with Alt, it should send a Latin F so that the US "File" menu could be accessed. Such a change was made on Windows early in the 1.9 cycle (and Linux followed much later).

The obvious problem with this (which was apparently not so obvious at the time) is that Greek users with Greek localizations could no longer access their Greek menus from the keyboard.

But, when restoring the original behavior was suggested, those who had got used to their preferred behavior with US builds complained.

Many bugs filed are like this in that they are related to what works best for a certain group of people, but may not work best for all people. We need to choose (or compromise) between what is improved behavior and what people have come to expect.

In bug 359638 – "accesskeys are incorrectly shifted again", Masayuki made changes that enable more than one group of people to have their preferred behavior because the events now contain more information (from the widget code) about the keyboard used.

There are several bugs open that are listed as blockers of that bug (some of which are regressions from that bug).

I'll summarize what I know about these.

bug 429970 – [Windows] Latin accel keys only function with Shift while in Hebrew layout

bug 429898 – [Windows] Zooming up with keyboard is broken for a Russian keyboard layout

These bugs and the windows part of

bug 429510 – Web apps cannot handle Ctrl+foo/Alt+foo key onkeypress event

were caused by changes to Windows widget code.

There is a patch now waiting approval that restores the previous Windows widget code behavior so as to fix these bugs (without regressing the bugs that were fixed by bug 359638).

(This patch is small, but could be split up into two parts to more closely represent the bugs that it fixes and enable a staggered landing if desired. It could perhaps even be split into more parts but that would require a significant amount of modification to some of the parts.)

bug 429219 – [Windows] Ctrl+1, Ctrl+2, etc, regression (on fr(-FR) keyboard), after bug 359638

This is an example of a situation where a particular desired behavior happened to exist at one stage but only existed at the expense of a different desired behavior.

Personally, I would not have marked this as a blocking bug.

Nevertheless, Masayuki has a patch awaiting review that would allow this desired behavior to exist where it does not conflict with the zoom-out shortcut key.

bug 429510 – Web apps cannot handle Ctrl+foo/Alt+foo key on keypress event

(Mentioned above.) This should perhaps be a different bug for each platform as it is widget code involved.

Here again the behavior has been different at different times in the past, and different on each platform.

The windows behavior will be fixed by the patch awaiting approval.

The Linux behavior is not a regression from FF2, but a small modification would make it consistent with Windows.

I know less about the Mac behavior, but my guess is that the major issues can be resolved easily, though details about (less important) corner cases may take more time.

bug 429217 – [Mac]Regression: Cmd+{ and Cmd+} will not switch tabs

This is not a blocker but some things that Masayuki is working on for bug 429510 would fix this.

bug 306585 – [Mac]Back and Forward keyboard shortcuts not working with Swedish/Finnish keyboard

Not currently a blocker. This was filed before bug 359638 was landed. The behavior requested here seems reasonable and apparently was implemented at one stage but https://bugzilla.mozilla.org/show_bug.cgi?id=429211#c2 indicates that this is not a regression from bug 359638.

That covers 3 of the 7 keyboard related blockers.

The Mac blockers seem to be unrelated:

bug 431080 – Keyboard shortcuts for page zoom are not working using cmd and number pad

bug 430499 – [10.5] Can't switch tabs with CTRL + Tab

This bug looks like it might need some attention.

The other blockers are also unrelated:

bug 430723 – Arrow keys stop working after going back one page

bug 430650 – '^' and '¨' chars don't work in password fields [with French keyboard]