We have a mistake at bug 359638 for accessibility. In nsContentUtils::GetAccelKeyCandidates(), the unshifted character is not added to the candidate list at Shift key is pressed. Therefore, we cannot user Accel+Shift+'unshiftedChar' for shortcut key. E.g., Accel+Shift+'.' cannot be used for shortcut key. Then, the current candidate list is: 1. Accel+Shift+'>' // from charCode 2. Accel+Shift+'>' // from shiftedCharCode but this is removed, actually. 3. Accel+'>' // from shiftedChar I think that we should create the following list: 1. Accel+Shift+'>' // from charCode 2. Accel+Shift+'>' // from shiftedCharCode but this is removed, actually. 3. Accel+Shift+'.' // from unshiftedCharCode 4. Accel+'>' // from shiftedCharCode But basically, this bug should not be occurred. Because non-alphabet keys have very many i18n accessibility issues. The XUL app developers should *not* use such keys for any shortcut keys. However, I think that we should fix this bug in 1.9.0 branch.

I think that this patch fixes this bug. But I cannot test this now, sorry.

(In reply to bug #359638 comment #154) > I am on a U.S(QWERTY) keyboard on WinXP, ctrl+shift+dot and ctrl+shift+/ > doesnt work for me in firefox3b5 and latest nightly (Mozilla/5.0 (Windows; > U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008051406 Minefield/3.0pre) > > Please try the following, FF2 takes ctrl+shift+. while FF3 takes > ctrl+shift+> instead. > > <key id="key-test-0" key=">" shift="true" modifiers="accel,shift" > oncommand="alert('Pressed key: >');"/> > <key id="key-test-1" key="?" modifiers="accel,shift" > oncommand="alert('Pressed key: ?');"/> > <key id="key-test-2" key="." modifiers="accel,shift" > oncommand="alert('Pressed key: DOT');"/> > <key id="key-test-3" key="/" modifiers="accel,shift" > oncommand="alert('Pressed key: /');"/> > > Am i doing something wrong? The behavior in FF2 seems to have been more a result of what was readily available from the OS rather than by any design, and so was different in different situations. On Windows, the behavior was to ignore the state of the Shift modifier when choosing the character in the event (because that was the information readily available from the OS event). The behavior on Mac was similar for most keyboard layouts, but, for "French - numerical" on OS X 10.4 at least, the state of the Shift modifier was taken into account (because that keyboard layout passed that information through the OS event). On Linux, the character depended on Shift (because GTK provided that information). I haven't seen a good use case for specifying the state of the Shift key in handlers for shortcuts involving punctuation characters (except to work around problems in FF2). Any keyboard shortcuts based on a character from a different level (Shift key state) would essentially be making assumptions about what other character might be on the same key, and could conflict with shortcuts using that other character. For example Shift+"," would correspond to "<" on a US QWERTY layout but could conflict with ";" on German, Dutch, Italian, Danish, Norwegian, Swedish, Portuguese, Spanish, or Turkish layouts, or "?" on French, Belgian, or Hungarian layouts. Also, Shift+"/", would correspond to "?" on a US QWERTY layout but could conflict with "/" on layouts where "/" is on the second level (requiring Shift): German, Italian, Danish, Norwegian, Swedish, Spanish, Hungarian. The best solution IMO is not to specify the Shift state in the handler, but only specify the character and accel: <key="?" modifiers="accel"> If support for FF2 is needed then that would best be provided with an additional handler (specifying Shift). FF2 already required both of these handlers anyway to support the various different behaviors according to platform and layout. Trying to provide support for matching "?" against <key="/" modifiers="Shift"> is likely to increase the number of shortcut conflicts (and cause problems like bug 433192), so I recommend WONTFIX here.

(In reply to comment #2) > Trying to provide support for matching "?" against <key="/" modifiers="Shift"> > is likely to increase the number of shortcut conflicts (and cause problems > like bug 433192), so I recommend WONTFIX here. Accel+Shift+'unshiftedChar' combination is sometimes used for an alternative command of Accel+'unshiftedChar'. That helps the users to memorize the shortcut. See http://www.mozilla.org/access/keyboard/index.html#modifiers # Note that the document also defines that punctuations should not be used for key combination. However, we cannot control the extension developers. So, some extensions might use both Accel+'.' and Accel+Shift+'.'. Then, the later combination is not accessible on the latest trunk. Of course, the conflict issue is too bad thing, so, the extension develpers should not use such key combination, however, such issue and this disaccessibility issue should be different. I think we should fix this bug.

(In reply to comment #3) > See http://www.mozilla.org/access/keyboard/index.html#modifiers "Try to group related functions together on the same key" section.

(In reply to comment #4) > (In reply to comment #3) > > See http://www.mozilla.org/access/keyboard/index.html#modifiers > > "Try to group related functions together on the same key" section. Both references here use the word "letter". They were not written to imply that the same situation should apply to punctuation. With letter keys, the upper and lower case characters are related. That is not the case with punctuation. "The accel letter combination can also be used with shift for a related command." "we try to reserve Accel+Shift+Letter for commands that are related to Accel+Letter, where possible." With punctuation, it is not possible to reserver the Accel+Shift+'.' because that could be any other punctuation character.

Any update here?

(In reply to comment #6) > Any update here? I'll be back to key hell ASAP. However, I'm working on some other bugs.

Doesn't really meet the "wanted" criteria (security, stability, regression from maintenance release) for 1.9.0.x. However, we'll look at a reviewed and baked patch. That said, this should probably get looked at for 1.9.1.

Is this still relevant?