Closed Bug 435164 Opened 16 years ago Closed 10 years ago

Remove Ctrl+Space shortcut for context menu (e.g. by backing out the patch for bug 357540)

Categories

(Core :: Widget: Cocoa, defect)

All
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla30

People

(Reporter: kohei, Assigned: jryans)

References

Details

(Keywords: access)

Attachments

(1 file)

On Bug 357540 – keyboard shortcut "Open context menu" (Control + space) doesn't work:

The patch should be backout because

- Other applications don't have such a shortcut.
- It breaks extensions to provide a capability to edit keybindings including https://addons.mozilla.org/ja/firefox/addon/4141
Flags: wanted1.9.0.x?
At least the 'feature' should be user configurable.
Summary: Patch of Bug 357540 should be backed out → Remove Ctrl+Space shortcut for context menu (e.g. by backing out the patch for bug 357540)
I'm not an accessibility expert, but I suspect accessibility is more important than the ability to edit key bindings.
Not sure what to do here... Aaron, thoughts?
(In reply to comment #0)
> - It breaks extensions to provide a capability to edit keybindings including
> https://addons.mozilla.org/ja/firefox/addon/4141

What does this feature do that breaks this?

Is there really no standard keyboard way of getting a context menu on a Mac? 

I recently read on the Apple Accessibility-Dev mailing list, that you have to run VoiceOver to get context menus with the keyboard. Once VoiceOver is running, ctrl-option-shift-M will bring up a contextual menu at the VoiceOver cursor point.
http://lists.apple.com/archives/Accessibility-dev/2008/Aug/msg00007.html

However, this is a problem for several reasons:
1. Firefox doesn't yet support VoiceOver:
http://accessgarage.wordpress.com/2008/08/21/firefox-and-os-xs-voiceover-reading-the-magic-8-ball/
2. Non-screenreader users also need keyboard access to the context menu. (On the thread they were actually suggesting that she turn on VoiceOver temporarily whenever she wants access to the context menu, even though she's also using speech recognition which can be annoying to combine with a screen reader).

My advice is, Apple is very confused here and isn't getting this right. We need some keyboard command to allow access to the context menu, although it doesn't have to be control+space if that causes a conflict somewhere.
Doesn't really meet the "wanted" criteria (security, stability, regression from
maintenance release) for 1.9.0.x. However, we'll look at a reviewed and baked patch.
Blocks: 357540
Flags: wanted1.9.0.x?
Flags: wanted1.9.0.x-
Flags: blocking1.9.1?
Keywords: access
Hardware: Macintosh → All
We need to provide a way to open a context menu via the keyboard and I don't see any good alternatives to what we're doing now presented here. Until this is resolved and we're sure of the seriousness of the problems this presents we're not going to block.
Flags: blocking1.9.1? → blocking1.9.1-
Assignee: joshmoz → nobody
This bug is now 2 years old... The author of the Firemacs add-on (see my comment 0) is still bothered by this.

This "feature" is Mozilla apps only, not a Mac OS X standard behavior. OS X and other Mac apps have no keyboard shortcut to open the context menus and all items in those menus are (should be) available from the menu bar (accessible with Ctrl+F2.) And, OS X uses the Ctrl+Space shortcut to focus the Spotlight search field by default. So I don't think this "feature" improves users' accessibility. Users would rather be surprised when they accidentally hit Ctrl+Space.

At least such a shortcut should not be hard-coded and should be in platformHTMLBindings.xml to be customizable:

http://mxr.mozilla.org/mozilla/source/content/xbl/builtin/mac/platformHTMLBindings.xml

e.g.

<handler event="keypress" key=" " modifiers="control" command="cmd_showContextMenu"/>

I hope you guys reconsider the request!
I guess one solution is to remap the shortcut to something else than Ctrl+Space.
See also Bug 534121
See also Bug 595762
This should be fixed anyway.
blocking2.0: --- → ?
Blocks: 595762
Blocks: 534121
blocking2.0: ? → -
blocking2.0: - → ?
Can't block since it's not clear what to do here.
blocking2.0: ? → -
No longer blocks: 595762
(In reply to comment #14)
> Can't block since it's not clear what to do here.

The summary reads: backing out the patch for bug 357540 :(
So, ctrl-space on my mac does nothing when in finder and mail...let's close this as wontfix? I'd back out the patch but I bet *some* people are relying on it and it seems like there isn't much downside to having this (spotlight is cmd-space in SL at least BTW).
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
Ctrl-space sets the mark in Emacs.  My fingers have been using this shortcut since 1991 - hard to unlearn now.  I use an AJAX terminal application (tty.js), which works fine with Firefox on Ubuntu and Win7, but does something different on OSX.  This is very annoying.  

I stopped using Chrome because it will not allow web apps to use Ctrl-n,w,t.  Now Firefox won't allow Ctrl-space.  Arrgh.
(In reply to Daniel Risacher from comment #17)
> Ctrl-space sets the mark in Emacs.  My fingers have been using this shortcut
> since 1991 - hard to unlearn now.  I use an AJAX terminal application
> (tty.js), which works fine with Firefox on Ubuntu and Win7, but does
> something different on OSX.  This is very annoying.  
> 
> I stopped using Chrome because it will not allow web apps to use Ctrl-n,w,t.
> Now Firefox won't allow Ctrl-space.  Arrgh.

Ah.  Bug 534121 is what I really want.
Someone has got to remove this bit of silliness, it's breaking incredibly important functionality like auto-complete. For example:

http://codemirror.net/demo/complete.html

We need web browsers to be more like desktop clients to create advanced applications, this behavior, and at minimum the inability to disable it, prevents this from happening with little to no gain for the vast majority of users.

What's more, this behavior isn't even consistent between the OS Versions Firefox officially supports. Try this shortcut in Windows and nothing happens. This is inconsistent and confusing. 

Finally, as others have pointed out I own not a single OS X application where this shortcut creates a similar context menu. Not Safari, Chrome, and certainly not any desktop application. 

In short, stop being stubborn and blast this "feature" back to the pit it came from.
It does seem unnecessary, I agree...

There seems to be decent way of achieving this accessibility feature at system level via Mouse Keys (pressing Ctrl-5 on a keypad / Fn-Ctrl-I without keypad), so it's not clear to me how this Mozilla-specific (and OS X specific) oddity provides value.
Wow, this is now a 5-year-old bug... Thanks, let's remove it then!
Status: RESOLVED → REOPENED
Flags: wanted1.9.0.x-
Flags: blocking1.9.1-
Resolution: WONTFIX → ---
This was wontfixed in 2011 (comment #19) and comment #5 from 2008 also suggests that this is/was the only way for mac users to invoke a context menu with the keyboard. I suspect that nothing have changed since then, so I'm not sure why this was re-opened.
stefanh: see comment 20.
Marco, sorry to dump this in your lap ... but what do you think we should do here?
Flags: needinfo?(marco.zehe)
We should definitely have a means for keyboard-only users who are *not* using VoiceOver to open the context menu for items they tab to or otherwise set focus on. If I remember correctly, Ctrl+Space is sort of the standard way to do this in OS X even in Mavericks.

The reason I mention keyboard users who are not also VoiceOver users is that VoiceOver has a very standard way to open the context menu for items. The command for them is Ctrl+Option+Shift+M, and that invokes a special method of the NSAccessibility protocol which brings up the context menu in all cases where applicable, or at least tries to, unless not implemented.

But keyboard users without VoiceOver need a means to do that, too. And the one thing that I see mentioned most often is CTRL+Space.

Hope this helps!
Flags: needinfo?(marco.zehe)
It is breaking auto-complete functionality to me. There should be a way to disable ctrl-space shortcut being mapped to context menu for user who do not wish to use this feature. It must be configurable.
I can confirm the standard keyboard shortcut, Function+Ctrl-I, shows the context menu on Firefox and other apps on MacBook Pro, as described in http://apple.stackexchange.com/questions/32715/how-do-i-open-the-context-menu-from-a-mac-keyboard
Marco, sorry to bother you again.  But do you think it's really acceptable to ask motion-impaired people to use Function+Ctrl+I to display the context menu?
Flags: needinfo?(marco.zehe)
If this also works with the Sticky Keys feature, meaning people can press each key separately before the command is executed on the actual press of the letter i, then yes this is acceptable.
Flags: needinfo?(marco.zehe)
Status: REOPENED → NEW
blocking2.0: - → ---
I'll come back to this bug once I have time to do some research and more thinking -- hopefully next week.
I'm on a MacPro and Function+Ctrl-I does not work for me. For what it's worth, I'm quite happy to have Control+Space as an option to invoke the context menu within Firefox. That being said, I'm not opposed to having it changed to some other shortcut as long as the ability to invoke the context menu via a keyboard shortcut is allowed to remain.
(In reply to ifmeister from comment #31)
> I'm on a MacPro and Function+Ctrl-I does not work for me.

Did you enable Mouse Keys first (System Prefs -> Accessibility -> Mouse & Trackpad -> Enable Mouse Keys)?  Also, to be more specific, if you are using a keyboard with a numpad, only Ctrl-5 will work.  Without a numpad, only Fn-Ctrl-I will work.  So, you can't use Fn-Ctrl-I on Apple's Extended Keyboard (even though you are able to press that key combination) since it has a numpad.
(In reply to J. Ryan Stinnett [:jryans] from comment #32)
> (In reply to ifmeister from comment #31)
> > I'm on a MacPro and Function+Ctrl-I does not work for me.

Hi Ryan and thanks for the reminder. Yes, Function+Ctrl-I will work but only with Mouse Keys enabled. In my case, I can omit the Function key altogether. Although useful, I find pressing the Option key five times to toggle Mouse Keys very cumbersome. A much more elegant solution to controlling the Mouse with your keyboard is KeyRemap4MacBook. 

https://pqrs.org/macosx/keyremap4macbook/
(In reply to J. Ryan Stinnett [:jryans] from comment #32)
> Did you enable Mouse Keys first (System Prefs -> Accessibility -> Mouse & Trackpad

Hi Ryan and thanks for the reminder. Yes, Function+Ctrl-I will work but only with Mouse Keys enabled. In my case, I can omit the Function key altogether. Although useful, I find pressing the Option key five times to toggle Mouse Keys very cumbersome. A much more elegant solution to controlling the Mouse with your keyboard is KeyRemap4MacBook. 

https://pqrs.org/macosx/keyremap4macbook/
Another case where usage of ctrl+space comes up is in autocompletion for the developer tools. We've already added a ctrl+space autocompletion hotkey for CSS authoring, but this doesn't work on OS X because the key isn't available. We're also going to be adding JavaScript autocompletion (bug 968896) that needs a keybinding.
(In reply to Brandon Benvie [:benvie] from comment #35)
> Another case where usage of ctrl+space comes up is in autocompletion for the
> developer tools. We've already added a ctrl+space autocompletion hotkey for
> CSS authoring, but this doesn't work on OS X because the key isn't
> available. We're also going to be adding JavaScript autocompletion (bug
> 968896) that needs a keybinding.

To add to this, ctrl+space is used for this autocompletion behavior on OSX for other code editors, like XCode and Sublime Text, and we'd like to follow this standard in DevTools.
So what do you suggest we could replace Ctrl+Space with (and then I don't mean fn+CTRL+I, see comment #10)?
(In reply to Stefan [:stefanh] from comment #37)
> So what do you suggest we could replace Ctrl+Space with (and then I don't
> mean fn+CTRL+I, see comment #10)?

What's bad about leaving it for the OS to provide as part of Fn+Ctrl+I?  I would think that's the approach that most of OS X apps would take for this.  Why is it valuable for Gecko to be different here?  It seems like this is exactly the kind of feature that *should* be left to the OS, so that it can be implemented in a consistent way across all applications.
(In reply to Marco Zehe (:MarcoZ) from comment #29)
> If this also works with the Sticky Keys feature, meaning people can press
> each key separately before the command is executed on the actual press of
> the letter i, then yes this is acceptable.

Just to reply to this specifically, it does indeed work with Sticky Keys.

So, you can press Fn, Ctrl, I (or Ctrl, Keypad 5 with an Extended Keyboard) to trigger it.
No reason to keep the current custom context menu. Please just remove it.
I meant the custom keyboard shortcut for the context menu.
(In reply to J. Ryan Stinnett [:jryans] from comment #38)
> What's bad about leaving it for the OS to provide as part of Fn+Ctrl+I?

The "bad" part is that:
1) atm there is a shortcut for it and it has been there for ages
2) In order to enable Fn+Ctrl+I you have to press the option key 5 times

I don't have any strong opinion about this, though - but I think someone from accessibility should weight in here considering 1) and 2) above.
Another thing to consider is that devs already block that shortcut if they need ctrl+space to perform a specific action. So it's not even consistent within the browser for the end-user.
(In reply to Stefan [:stefanh] from comment #42)
> (In reply to J. Ryan Stinnett [:jryans] from comment #38)
> > What's bad about leaving it for the OS to provide as part of Fn+Ctrl+I?
> 
> The "bad" part is that:
> 1) atm there is a shortcut for it and it has been there for ages
> 2) In order to enable Fn+Ctrl+I you have to press the option key 5 times

Yes, that's true.  It's not as bad if you have an Extended Keyboard, since Mouse Keys just take over the numpad, so it could probably be left on.

> I don't have any strong opinion about this, though - but I think someone
> from accessibility should weight in here considering 1) and 2) above.

Hmm, well, I thought Marco's last answer was pretty clear, but I suppose we can double-check to be sure.

Marco, sorry to ask about this again...  In your last response, you seemed to feel okay with removing Ctrl + Space if Fn + Ctrl + I works with Sticky Keys, and indeed it does.  Do Stefan's points in comment 42 change that answer, or does it still seem okay to remove Ctrl + Space as a context menu shortcut?
Flags: needinfo?(marco.zehe)
Nope, my answer still stands. :)
Flags: needinfo?(marco.zehe)
Assignee: nobody → jryans
Status: NEW → ASSIGNED
This removes the Ctrl + Space mapping, bringing Cocoa into parity with other Gecko platforms.

Try: https://tbpl.mozilla.org/?tree=Try&rev=88dadbe2d925
Attachment #8388007 - Flags: review?(smichaud)
Comment on attachment 8388007 [details] [diff] [review]
Stop mapping Ctrl+Space to context menu on Cocoa

Now that we've reached something like a consensus, this looks fine to me.
Attachment #8388007 - Flags: review?(smichaud) → review+
https://hg.mozilla.org/mozilla-central/rev/eb99c9d72f30
Status: ASSIGNED → RESOLVED
Closed: 13 years ago10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
Depends on: 1023945
I was forced against my will by Firefox to upgrade to 30.0 on my Mac OS X 10.6.8, and now control-space does not work. This is an absolutely essential feature to my workflow because I use it to http://www.borngeek.com/firefox/colt/ . Please tell me: How do I get this behavior back? Also, was this intentional? Thank you.
This change is absolutely intentional as I described in my Comment 0. A standard OS X keyboard shortcut is available; see Comment 20.
Oops - sorry I didn't read that first. That's what I get for hurrying.

I tried the workaround you listed in your comment, but it didn't work. This is an important point, so let me put clearly: You removed a working feature that has been in FF for a long time, thereby screwing up my (and maybe others'?) hourly workflow. You suggested that I adopt a new way to activate the feature you removed, but the simple-sounding answer ("just type Fn-Ctrl-I") didn't work, so now I would have to start using a system feature that, given my experience, would likely break something else. That is unacceptable to me as a user. As a developer that should bother you a little. (We like happy users, right?)


Stepping back, this change you made is a good example of a certain level of developer arrogance that the Firefox team has been demonstrating  for a while now. I don't know the organization well enough to speculate why this has happened, but Apple and Google do this too (i.e., removing or changing perfectly important features apparently without adequate regard to impacted users), so maybe it's related to feeling too big to fail. I honestly don't know, but what I do know as a long time FF user is that you've recently been yanking essential features out from under me, with this being the latest example. (See https://bugzilla.mozilla.org/show_bug.cgi?id=537013 for another nasty one.)

I care about your work, which is why I'm writing some detail. You're making it harder to like FF, both the artifact and the process/attitude towards users. My 2c.
You need to enable Mouse keys: System Preferences -> Accessibility -> Mouse and Trackpad -> "Enable Mouse Keys"

As for the rest of your comment, complaining here is the wrong place to do that. The point of this bug is to be consistent with the OS, so file an Apple bug to implement a global shortcut to do what you want.
Matthew: You may want to contact the author of CoLT to ask him to provide its own keyboard shortcut, or as :JosiahOne said, ask Apple to make Ctrl+Space the standard shortcut. Or their might be another extension offering a similar feature as well as a convenient keyboard shortcut.

The reason why this feature has been in Firefox for a long time is, IIUC, we simply didn't know the standard shortcut provided by OS X.
Matthew, responding to your points about "happy users" and "developer arrogance": 

I would like to point out that this change was *requested by users* (like myself), and has been carefully debated and considered by the Firefox team for MORE THAN FIVE YEARS.  They can't make everyone happy as the same time...  This is hardly a case of developer arrogance yanking out features willy-nilly.  

While I might wish that the process were swifter, I appreciate the extreme care and diligence that the team has shown.  

Marco, Ryan, Stefan, et al.: Thank you.
Thank you for the explanation, Daniel. I see that I'm coming to this from a very different direction than developers and users. I shared the experience from my perspective, which is simple and valid: You removed a feature that I depend on for daily use, and not for the first time. Also, and I realize this has probably fallen out of fashion, no one apologized.
(In reply to Josiah Bruner [:JosiahOne] (needinfo for responses) from comment #53)
> As for the rest of your comment, complaining here is the wrong place to do
> that. The point of this bug is to be consistent with the OS, so file an
> Apple bug to implement a global shortcut to do what you want.

Not really. Apple's take is "Always ensure that contextual menu items are also available as menu commands":
https://developer.apple.com/library/content/documentation/UserExperience/Conceptual/OSXHIGuidelines/ContextualMenus.html#//apple_ref/doc/uid/20000957-CH30-SW1
I.e. the context menu should never be the only way to access some functionality, and that's probably the reason why there's no standard shortcut for that in macOS.

But in Firefox, the context menu contains commands that are not accessible anywhere else (spell checking suggestions, Inspect Element). To make Firefox accessible again, you should bind Open Context Menu to an other shortcut, e.g. Shift+F10 like on other platforms.

Unfortunately, the native Voice Over (Command-F5) command "shortcut menu" (Control-Option-Shift-M) doesn't work in Firefox either, so there's no way left to open the context menu on the selection.

Mouse Keys is not a replacement, since Mouse Keys only allows the user to click at the location of the mouse pointer. In contrast, the context menu command opens the menu at the text cursor location or selected/focused element.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: