View source for 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]