569781 - Prevent web content from overriding non-US-layout window cycling keys

Status: RESOLVED INCOMPLETE

(Camino Graveyard :: Toolbars & Menus, defect)

Description

[Stuart Morgan]

Bug 569130 didn't fix window cycling for any layout that doesn't use `/~:

> 2) Unfortunately, the shortcut for Cycle Windows is different per keyboard
> layout (and possibly other factors, like UI locale), e.g. on AZERTY, it's
> Cmd-Ctrl-< (Cmd-Ctrl->, aka Cmd-Ctrl-Shift-<, for reverse-cycle); searching
> "key hell" bugs should turn up others, and we can also poke l10n if needed.

We need to figure out a better solution for that case. Might need core cooperation so that command keys always come back out of web content so we can get them after the fact, since I'm not sure we can find out what the actual shortcut is for a given user dynamically.

Comment 1

[philippe (part-time)]

As I was afraid, the cycle through windows is still swallowed on my side (10.6.3).

hardware: stock Apple JIS aluminium keyboard.

1. The default shortcut on En-us locale (my usual settings) is Cmd+`. This shortcut never worked except in the Finder and Textedit. I customized this to Cmd+shift+@. The '`' and '@' share the same key on this keyboard, to access '`' I need to press 'shift'.

2. Under a Japanese locale (freshly created user account) the same problem happens: the default shortcut (as listed in the Finder's menu) is Cmd-(fn)-F1. This does not work in Camino (or Safari) - and is swallowed by the keyboard-shortcut-swallowing-monkey with the testcase in bug 569130.

(I'll test later on 10.5.8)

Comment 2

[Stuart Morgan]

There's no need to test on 10.5.8. The summary on this bug isn't perfect because it's hard to describe accurately in a short summary, but the behavior is known:
1) If your shortcuts are Commmand + <a key that generates ` when pressed without other modifiers> and Command + Shift + <a key that generates ~ when pressed with no modifiers other than shift>, then they will work
2) If not, they won't.

It's not actually about locales or keyboard layouts except as those cause 1) not to be true. Similarly, customized shortcuts will be broken no matter the layout.

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Again, I'd have expected to hear more issues with this, but since we haven't, and this sounds really difficult :-( …