| Summary: | Use of Ctrl as access key modifier conflicts with Mac OS X emacs-style keybindings | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | rahul abrol <solushex> | ||||
| Component: | Accessibility | Assignee: | Nobody <webkit-unassigned> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Enhancement | CC: | ap, ian, jruderman, mrowe | ||||
| Priority: | P2 | Keywords: | InRadar | ||||
| Version: | 420+ | ||||||
| Hardware: | Mac | ||||||
| OS: | OS X 10.4 | ||||||
| Attachments: |
|
||||||
|
Description
rahul abrol
2006-02-25 15:59:42 PST
This drives me nuts. It's most annoying when working with Bugzilla. Ctrl-e takes me to the Severity dropdown list rather than the end of line like in other applications, and Ctrl-a takes me to Add CC rather than to the beginning of the line. I would at least like a way to disable access keys altogether, if it's not possible to use something other than ctrl for them. Access keys are completely inconsistent across sites, completely non-discoverable (having no visual cue) to the user, and are mapped to bindings that many people use already for other purposes. This seems broken to me. I want the ctrl+letter shortcuts all to myself. ;) I second that this is The Most Annoying Bug in the Observable Universe. i noticed this was fixed in safari 3 by disabling accesskeys inside text fields, but now it's returned in TOT. i've tracked the change to between r24285 and r24399 but can't find the code. was this intentional, or a regression? what's the plan? This bug has caused me dataloss (I was in a form field, I pressed ctrl+e to go to the end of the line, and it navigated away from the page). I had to look at the page source to work out what Ctrl+E was supposed to do, since it didn't highlight a menu like Mac apps normally do when I hit an accelerator. Created attachment 20310 [details]
change access key modifiers to Ctrl+Option on Mac
One approach to fixing this is to have different modifiers for access keys. The only semi-available combination I see is Ctrl+Option (Option alone, as well as Option+Shift, are used for typing special characters; Ctrl+Shift conflicts with Kotoeri shortcuts).
Opinions?
what do other mac browsers do? do they allow access keys to work in text controls? Firefox doesn't support Emacs key bindings, so it doesn't have this problem (but as mentioned above, it has a preference for changing the modifiers). I've been told that Firefox 3 on Windows changes the default from Ctrl to Ctrl+Shift. Opera doesn't seem to support accesskey the way other browsers do - instead, a list of keys appears when one presses Shift+Esc. (In reply to comment #10) > Firefox doesn't support Emacs key bindings, so it doesn't have this problem it does. so does opera, actually. how about a preference, webkitaccesskey: 0: none 1: ctrl (default) 2: ctrl+alt ? (In reply to comment #11) > (In reply to comment #10) > > Firefox doesn't support Emacs key bindings, so it doesn't have this problem > > it does. Indeed, I was wrong. So, it's just the priority of Emacs key bindings and access keys that is different, apparently. > so does opera, actually. Yes, I never said it didn't. But the support is broken anyway, as some of the bindings are taken by the application. E.g., Ctrl+E takes one to Help screen (as of a 9.50 beta that I have installed). Comment on attachment 20310 [details]
change access key modifiers to Ctrl+Option on Mac
I'm worried that people who make use of accesskey will think it's just broken. But this looks like it was executed just fine.
r=me
Landed in <http://trac.webkit.org/projects/webkit/changeset/34259>. So, it's Ctrl+Option for access keys on the Mac now, let's see if we get many complaints. See bug 21107: Control+Option conflicts with VoiceOver. |