Closed Bug 207510 Opened 22 years ago Closed 11 years ago

Use command, rather than control, as accesskey accelerator in chrome on Mac

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

All
macOS
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: bugmail, Unassigned)

References

(Blocks 2 open bugs)

Details

(Keywords: helpwanted)

Attachments

(1 file, 1 obsolete file)

Since Mac OS uses command rather than control as the accelerator key, so should Mozilla do in chrome. For example, open a new Composer window, type foo, and click the window close widget. In the resulting Save dialog, press control+d. Mozilla interprets this as selecting the Don't Save command, and closes the window. Command+d should work in this situation, not control+d.
-> brade, to decide what to do with it
Assignee: aaronl → brade
Is this the only example or are there other dialogs affected? Is it only dialogs or is there some other example that is broken and doesn't have a bug already?
The cookie deny/allow dialog only has an accesskey set on the Show Details button, and it has the same problem; control+s, rather than command+s.
-->aaronl The issue seems to be that there is only one pref for xul dialogs and html pages. If this pref is changed to command key, the dialogs respond appropriately: "ui.key.generalAccessKey" However, changing the value of that pref would impact html web pages with accesskeys so it is not a reasonable option. Instead, we need a separate pref or use "ui.key.accelKey" and a check in nsEventStateManager::PreHandleEvent to know if we are in an html page or a xul dialog and use the appropriate modifier key.
Assignee: brade → aaronl
Depends on: 124416
Keywords: helpwanted
Blocks: 265277
Blocks: 124416
No longer depends on: 124416
Depends on: 282222
Depends on: 340902
With bug 340902 fixed, fixing this bug should now be as simple as modifying line 1563 of all.js to the appropriate value: pref("ui.key.chromeAccess", 2); I won't however be able to provide a patch since I've currently got no idea which key code the Command key is mapped to (Alt or Meta?).
1560 // If generalAccessKey is -1, use the following two prefs instead. 1561 // Use 0 for disabled, 1 for Shift, 2 for Ctrl, 4 for Alt, 8 for Meta 1562 // (values can be combined, e.g. 3 for Ctrl+Shift) 1563 pref("ui.key.chromeAccess", 2); 1564 pref("ui.key.contentAccess", 3); Shouldn't those be set to 8 and 2, respectively? Cmd is mapped to Meta, and there's no reason to change the content access key away from Ctrl on the Mac (none of the other content-vs-chrome bugs influencing bug 340902 apply here, and changing it from Ctrl breaks platform consistency)....
Attachment #229342 - Flags: review?(aaronleventhal)
Attachment #229342 - Flags: review?(aaronleventhal) → review?(mats.palmgren)
Yes, we were probably a bit over-protective when we required shift to invoke content accesskeys for MacOS, since the clash is not as severe here as for other systems. So, setting "ui.key.contentAccess" to 2 is ok. I'm not so sure about using Cmd for "ui.key.chromeAccess" though. Just as an example, try Preferences->Advanced->General, type Cmd+m. It minimizes the window, not toggles the "Use smooth scrolling". Another example: type Cmd+f (opens the Find box), then try to do "Highlight all" with the keyboard (accesskey is 'a'). As far as I can tell, changing "ui.key.chromeAccess" to Cmd would make most chrome accesskeys useless since the menu accelerator will be invoked instead. Personally, I think it's unfortunate since it would break major parts of keyboard accessibility we currently have unless those users that depends on it manually changes "ui.key.chromeAccess" back to Control. I'm not very comfortable with making such a change to fix the issue reported in this bug. Aaron, what do you think?
I want to stay out of Mac kbd issues. You can get a good opinion from Hwaara.
Assignee: aaronleventhal → nobody
Cmd-* and even Cmd-shift-*/Cmd-alt-* is heavily used and so we can't use that for accesskeys. Maybe something like alt for chrome and ctrl for content? Those are usually not reserved/used for the application, so it should be quite safe.
BTW, we should look at what Safari/OmniBrowser et al do.
Traditionally, Mac apps have only accelerated buttons in modal dialogues, not random preference options (moving between preference options and similar widgets is the domain of full keyboard access). So in TextEdit, when closing a document with unsaved changes, Cmd-D will trigger "Don't save" but it (or any almost other cmd-key combo) does nothing in prefs. In the Mozilla system, if you were to use Opt (Alt) for a chrome access key and if you're currently focused in a text field (which *should* be the default focus in any prefpanes that have them), opt-foo will insert the composed character instead of triggering whatever pref had "foo" as its access key (or you'll break the use of compose), e.g. opt-a would insert a-ring in the Find example mentioned by Mats. Because of its primary binding to "compose", Opt is only acceptable as a modifier on Mac OS X, not as a full-fledged accelerator. If there's going to be significant study required wrt this bug (chrome accelerator), can we quickly/separately fix the regression in content access key (set it back to ctrl like all other meaningful Mac browsers)?
I agree with Smokey that the content access keys parity with other browsers is higher priority to fix than the chrome access keys. Mainly because normal mac apps don't have as many accesskeys, except for special cases mentioned in the previous comment (dialogs). Here's a proposed fix. It makes content use Ctrl and (temporarily?) lets the chrome use Ctrl-shift. The latter may change if we come up with something better.
Attachment #229644 - Attachment is patch: true
Attachment #229644 - Attachment mime type: application/octet-stream → text/plain
Attachment #229644 - Flags: review?(mats.palmgren)
Nah nah nah nah, this is to get Command keys working in alert dialogs and such. Command is the appropriate key. Option works now, but is the wrong key. What we need here is Command in chrome and something else in content.
(In reply to comment #14) > Nah nah nah nah, this is to get Command keys working in alert dialogs and such. Greg, we know that the current discussion regarding solutions to the regression does not solve the problem you reported.
Comment on attachment 229644 [details] [diff] [review] Make content accesskeys use Ctrl (checked in) I would prefer "ui.key.chromeAccess" = 2 also. That puts it back like it was before bug 340902 regarding MacOSX access keys. r=mats with that. There really is no conflict in having both set to Control, since the context will decide what we do (eg. Ctrl+a in Find activates "Highlight all" even for this bug page that has access key 'a' for "Add CC"), so I don't see the need to require Shift as well. I want to keep it as it were so that users don't need to re-learn a new key combo (at least until we have a solution for the original problem reported in this bug).
Attachment #229644 - Flags: superreview?(roc)
Attachment #229644 - Flags: review?(mats.palmgren)
Attachment #229644 - Flags: review+
Attachment #229342 - Attachment is obsolete: true
Attachment #229342 - Flags: review?(mats.palmgren)
Comment on attachment 229644 [details] [diff] [review] Make content accesskeys use Ctrl (checked in) sr+ with Mats' suggestion of setthing chromeAccess to 2
Attachment #229644 - Flags: superreview?(roc) → superreview+
Comment on attachment 229644 [details] [diff] [review] Make content accesskeys use Ctrl (checked in) This part of the bug has been fixed on trunk.
Attachment #229644 - Attachment description: Proposed fix → Make content accesskeys use Ctrl (checked in)
The patch was incorrectly associated with this bug, which is explicitly about using the Command key in chrome. I know, I could just open another, but personal reasons hinder me just now. Help?
(In reply to comment #19) > The patch was incorrectly associated with this bug, which is explicitly about > using the Command key in chrome. I know, I could just open another, but > personal reasons hinder me just now. Help? This bug will remain open until the original issue is resolved. I don't see what's so bad about us fixing the obvious regression in the meantime, even if it wasn't strictly the issue you filed.
Blocks: 444960
Blocks: 471283
QA Contact: bugzilla → keyboard.navigation
Given that Cmd-D is widely accepted as the key combo for the "Don't Save" button in a close dialog, it would be nice to have the same combination in Thunderbird, too.
I hit Cmd-D 4 times today for that dialog, and each time was irritating. First day using Thunderbird 3. Voting up.
Hardware: PowerPC → All
just voted this bug up again. Cmd-D as accelerator for "Don't Save" in the dialog is the correct behavior. from all of the comments above, it apparently used to be the case that other accelerators worked, and now they do not. and shouldn't. only Cmd-D should work. and thus this should be fixed.
I got all excited for a moment then. I thought something had actually been done for this bug. Turns out it hasn't it was some other bug that just wanted to spam this one. Never mind, after all this bug's only just coming up to it's 9th birthday. I shouldn't expect anything to be done about it in such a short timescale.
Well more than 10 years after this missing feature has been filed, I express my deep wish to have it actually done. There are Add-ons that allow customize keyboard shortcuts. But this is not the way users should go, since the feature request in this bug report is indeed the only "right" way to address this issue. The number of duplicate bugs and the comments in them suggest that there is quite some part of the Mac based TB users irritated by this bug. BTW: I am not really familiar with the bug status, but "NEW" hardly complies with my understanding of new... Anyone who solves this bug would earn a postcard from Zurich or a beer. I created my account here to write this post.
Seems like this big should be closed as fixed, since the issue is not that Mac TB needs to use CMD instead of Ctrl -- because it already does. Not totally sure, but what I think the remaining concern here is the 'Don't Save' box from the compose window. That issue is being covered in but 768797 https://bugzilla.mozilla.org/show_bug.cgi?id=768797
Please file new bugs (one per issue) if the are any remaining problems apart from the already known bug 768797. Thanks.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: