All users were logged out of Bugzilla on October 13th, 2018

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




16 years ago
5 years ago


(Reporter: bugmail, Unassigned)


(Blocks: 2 bugs, {helpwanted})

Mac OS X
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(1 attachment, 1 obsolete attachment)



16 years ago
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.

Comment 1

16 years ago
-> brade, to decide what to do with it
Assignee: aaronl → brade

Comment 2

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

Comment 3

16 years ago
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.

Comment 4

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


15 years ago
Depends on: 124416


15 years ago
Keywords: helpwanted


14 years ago
Blocks: 124416
No longer depends on: 124416


14 years ago
Depends on: 282222


13 years ago
Depends on: 340902

Comment 5

12 years ago
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)....

Comment 7

12 years ago
Created attachment 229342 [details] [diff] [review]
Use Cmd for chrome and Ctrl for content
Attachment #229342 - Flags: review?(aaronleventhal)


12 years ago
Attachment #229342 - Flags: review?(aaronleventhal) → review?(mats.palmgren)

Comment 8

12 years ago
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?

Comment 9

12 years ago
I want to stay out of Mac kbd issues. You can get a good opinion from Hwaara.
Assignee: aaronleventhal → nobody

Comment 10

12 years ago
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.

Comment 11

12 years ago
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)?

Comment 13

12 years ago
Created attachment 229644 [details] [diff] [review]
Make content accesskeys use Ctrl (checked in)

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.


12 years ago
Attachment #229644 - Attachment is patch: true
Attachment #229644 - Attachment mime type: application/octet-stream → text/plain
Attachment #229644 - Flags: review?(mats.palmgren)

Comment 14

12 years ago
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+


12 years ago
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 18

12 years ago
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)

Comment 19

12 years ago
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?

Comment 20

12 years ago
(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.


10 years ago
Blocks: 444960


10 years ago
Duplicate of this bug: 456812


10 years ago
Blocks: 471283
Duplicate of this bug: 249778
QA Contact: bugzilla → keyboard.navigation
Duplicate of this bug: 480681
Duplicate of this bug: 474555
Duplicate of this bug: 483441


10 years ago
Duplicate of this bug: 339996


10 years ago
Duplicate of this bug: 124416

Comment 28

10 years ago
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.

Comment 29

9 years ago
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
Duplicate of this bug: 545354

Comment 31

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

Comment 33

5 years ago
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.

Comment 34

5 years ago
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
Please file new bugs (one per issue) if the are any remaining problems apart from
the already known bug 768797.  Thanks.
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.