User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.0.5) Gecko/2008120121 Firefox/3.0.5 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.0.5) Gecko/2008120121 Firefox/3.0.5 On Windows, HTML4 access keys are accessed with SHIFT+ALT. On UNIX, these keys are accessed with SHIFT+CNTRL. For some reason, on Mac OS X, these are accessed with CNTRL+key (no shift). The OS X behavior should be made to match the UNIX behavior. (arguably, the UNIX behavior should be the behavior across all platforms) Using simply CNTRL+key masks keys from plugins like Vimperator that use these CNTRL+keys to kick off features. In one particular example, Vimperator's external editor (triggered with ^I) is useless on Wikipedia pages because their "This is a minor edit" has an accesskey of "i". Reproducible: Always Steps to Reproduce: 1. Load a plugin (or some JavaScript) that triggers an action with CNTRL+i. 2. Visit the URL above that has an input checkbox that has accesskey="i". 3. Press CNTRL+i to trigger the plugin action (e.g., call Vimperator's external editor while in the textarea). Actual Results: The plugin functionality is hidden forever because the accesskey grabs it. Expected Results: On other platforms, there is no problem because CNTRL+SHIFT is required. The extra SHIFT solves the problem. The plugin is able to launch its CNTRL+(key) functionality.

The problem is that ui.key.contentAccess=2 by default on Mac OS X. Setting ui.key.contentAccess=3 causes Mac OSX to behave like UNIX. The default setting goes against the kb.mozillazine.org advice given in: http://kb.mozillazine.org/Ui.key.contentAccess In particular, the article suggests that setting ui.key.contentAccess = ui.key.chromeAccess is a bad idea. However, on Mac OS X, they both default to 2. It's a better idea to make the former default to 3.

(In reply to comment #0) > On UNIX, these keys are accessed with SHIFT+CNTRL. For some reason I've mistyped that originally and this still hasn't been corrected everywhere: On Linux, content accesskeys are accessed with ALT+SHIFT like on Windows. > In one particular example, Vimperator's external editor (triggered with ^I) This sounds wrong, though. Ctrl+I on the Mac, as confusing as this may sound, should behave the same as hitting Alt+I on Windows. Vimperator should rather react to Cmd+I on OS X (i.e. its author should use modifiers="accel" instead of modifiers="ctrl" for proper cross-platform behavior).

> For some reason I've mistyped that originally and this still hasn't been > corrected everywhere: On Linux, content accesskeys are accessed with ALT+SHIFT > like on Windows. Okay. Then CMD+SHIFT should probably be the default on Mac. (or Option+Shift, but Cmd+Shift makes more sense) > > In one particular example, Vimperator's external editor (triggered with ^I) > > This sounds wrong, though. Ctrl+I on the Mac, as confusing as this may sound, > should behave the same as hitting Alt+I on Windows. Vimperator should rather > react to Cmd+I on OS X (i.e. its author should use modifiers="accel" instead of > modifiers="ctrl" for proper cross-platform behavior). The choice of Ctrl was deliberate. Vimperator emulates Vim, and Vim makes use of Ctrl. Additionally, all of the Cmd+(key) combinations are already mapped to menu options. In this case, Cmd+I brings up Page Info (as it should). So it seems natural for plugin developers to use Ctrl, and it makes sense for access keys to be accessed with either Cntrl+Shift or Cmd+Shift.

FWIW, Safari is also moving away from Ctrl: https://bugs.webkit.org/show_bug.cgi?id=7466 Not sure why they moved to Ctrl+Opt instead of Ctrl+Shift.

(In reply to comment #4) > Not sure why they moved to Ctrl+Opt instead of Ctrl+Shift. https://bugs.webkit.org/show_bug.cgi?id=7466#c8 : "Ctrl+Shift conflicts with Kotoeri shortcuts)." In Gecko, Ctrl was chosen at the time to match other Mac browsers (e.g., IE) and to avoid conflicting with accelerators (i.e., preventing bug 128452-like problems from ever happening on the Mac). http://mxr.mozilla.org/mozilla-central/source/modules/libpref/src/init/all.js#1938 If Safari and other Mac browsers make a concerted effort to abandon Ctrl, it's probably reasonable for Gecko to move to the same shortcut as the default (the change doesn't seem to have made it into a release Safari yet, since Ctrl alone still triggers access keys in 3.2.1. It will be interesting to see if it sticks, given Apple's penchant for changing shortcuts, and/or spreads beyond Safari, for instance to OmniWeb, which ships a custom WebKit, or iCab, which builds in lots of work-arounds/custom fixes for bizarre WebKit behaviors). (In reply to comment #3) > Okay. Then CMD+SHIFT should probably be the default on Mac. (or Option+Shift, > but Cmd+Shift makes more sense) Cmd-Shift will break menu accelerators (and irritate extension authors, who are often forced to cherry-pick what's left of them for their own menu shortcuts) and Opt-Shift will break keyboard entry and IME. There's no good shortcut here (note that even Ctrl-Opt breaks VoiceOver and has to be special-cased), but the most obscure shortcut is probably the best (Ctrl-Shift-Opt, anyone? :P); barring that, the combination that is widely adopted as the platform standard. And relnoted to the end of the world. Somebody really ought to write a spec some day on how all this @#$@#$ crappy keyboard-shortcut stealing in web pages should be allowed to work :P (I'm not sure why this depends on bug 207510; that bug is about making chrome accelerators use Cmd like the rest of Mac OS X, e.g. for the "Save" button in the Save dialogue to use Cmd-S instead of the Windows-y Ctrl-S.)

(In reply to comment #5) > (In reply to comment #4) > > Not sure why they moved to Ctrl+Opt instead of Ctrl+Shift. Where is the "Opt" bit in ui.key.contentAccess? Does a sixth bit need to be added? > There's no good shortcut here (note that even Ctrl-Opt breaks VoiceOver and has > to be special-cased), but the most obscure shortcut is probably the best > (Ctrl-Shift-Opt, anyone? :P); barring that, the combination that is widely > adopted as the platform standard. And relnoted to the end of the world. Ctrl+Opt+Cmd is a convenient combination. They're next to each other. (but Cntrl+Opt+Shift seems to be closer to what you get on the other platforms... where "Cntrl+Opt" takes the place of "Alt") I would suggest Ctrl+Opt+Cmd as the default, and then let people change things after that. Keep in mind that it's very simple to change accelerator keys via System Preferences. When Skim users started bitching about key combinations, Skim's head developer just told them to consult their System Preferences, and that shut everyone up, and everyone seemed happy. > (I'm not sure why this depends on bug 207510; that bug is about making chrome > accelerators use Cmd like the rest of Mac OS X, e.g. for the "Save" button in > the Save dialogue to use Cmd-S instead of the Windows-y Ctrl-S.) Maybe it has something to do with ui.key.contentAccess=ui.key.chromeAccess by default (against the advice on mozilla zine?). I dunno. I didn't do it, but that's my guess.

(In reply to comment #6) > Where is the "Opt" bit in ui.key.contentAccess? Opt is just Mac's quirky name for "Alt" :)

Using ctrl as the modifier also now conflicts with OS X with regards to Spaces. Shouldn't the default Firefox accesskey different on the Mac be the same as the Windows and Linux access keys (alt-shift)?

Alt+Shift is very much taken on Mac for typing extra characters, e.g. Alt+Shift+2 for €.

Safari's managed to stick with Ctrl-Opt for two whole versions (4 and 5) now, so I think that's what we ought to move content access keys to on Mac OS X (chrome "accesskeys" need to use Cmd, as bug 207510 mentions, once all the issues there are resolved). If we ever get accessibility working in Gecko, we can implement the same special-casing behavior as WebKit. (Chrome appears to use Ctrl-Opt on Mac OS X, too, although accesskey support seems very unreliable; it's not working on Bugzilla, but does on things like http://bip.cnrs-mrs.fr/bip10/cv.htm. Opera uses something so bizarre it defies explanation, so it's safe to ignore. The momentum—and platform expectations—clearly lie with WebKit in this case.)

I can’t find the change, but accesskeys appear to have been switched over to Ctrl+Opt in Aurora very recently: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120428 Firefox/14.0a2

Ah, sorry for the spam; I didn’t notice Masayuki’s change above.