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 (edit)" Bug 429898 – [Windows] Zooming up with keyboard is broken for a Russian keyboard layout (edit)

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 (430499) 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]