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

NEW
Unassigned

Status

Camino Graveyard
Toolbars & Menus
8 years ago
6 years ago

People

(Reporter: Stuart Morgan, Unassigned)

Tracking

Details

(Reporter)

Description

8 years ago
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

8 years ago
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)
(Reporter)

Comment 2

8 years ago
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.
Again, I'd have expected to hear more issues with this, but since we haven't, and this sounds really difficult :-( …
Flags: camino2.1? → camino2.1-
You need to log in before you can comment on or make changes to this bug.