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

Status: RESOLVED WORKSFORME

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

Description

[Greg K.]

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

[Aaron Leventhal]

-> brade, to decide what to do with it

Comment 2

[Kathleen :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?

Comment 3

[Greg K.]

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

[Kathleen :Brade]

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

Comment 5

[Simon Bünzli]

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?).

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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

[Simon Bünzli]

Attachment: Use Cmd for chrome and Ctrl for content

Comment 8

[Mats Palmgren (inactive)]

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

[Aaron Leventhal]

I want to stay out of Mac kbd issues. You can get a good opinion from Hwaara.

Comment 10

[Håkan Waara]

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

[Håkan Waara]

BTW, we should look at what Safari/OmniBrowser et al do.

Comment 12

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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

[Håkan Waara]

Attachment: 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.

Comment 14

[Greg K.]

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.

Comment 15

[Mats Palmgren (inactive)]

(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 16

[Mats Palmgren (inactive)]

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).

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 229644 [details] [diff] [review]
Make content accesskeys use Ctrl (checked in)

sr+ with Mats' suggestion of setthing chromeAccess to 2

Comment 18

[Håkan Waara]

Comment on attachment 229644 [details] [diff] [review]
Make content accesskeys use Ctrl (checked in)

This part of the bug has been fixed on trunk.

Comment 19

[Greg K.]

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

[Håkan Waara]

(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.

Comment 28

[Morten Norby Larsen]

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

[Karl Shea]

I hit Cmd-D 4 times today for that dialog, and each time was irritating. First day using Thunderbird 3. Voting up.

Comment 31

[xolaware.llc]

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.

Comment 32

[Not interested in Mozilla any more]

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

[Fabian Egli]

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

[Chris Andrichak]

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

Comment 35

[Mats Palmgren (inactive)]

Please file new bugs (one per issue) if the are any remaining problems apart from
the already known bug 768797.  Thanks.