In Firefox of 1.8branch build, there is no problem. It reproduces with Firefox of trunk. The problem might have been brought up by the thing that changed into Cocoa widget(bug326469). Mac OS X 10.3.9 Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20061021 Minefield/3.0a1

> The problem might have been brought up by the thing that changed into Cocoa > widget(bug326469). Yeah, looks like it. It works in Firefox trunk 2006-09-28-08, but not in 2006-09-29-06 (10.3.9). Fwiw, it doesn't work in Seamonkey either (Oct 25, trunk).

oops, sorry - forgot to add the dependant bug...

According to Bug 160782, this bug should be WONTFIX. Other Mac apps don't have such a shortcut. On Mac OS X v10.4 Tiger, Ctrl+Space is assigned to activate its Spotlight search bar.

Bug 160782 is a Camino bug. Firefox is welcome to make its own UI decisions, but you shouldn't close this bug just because the Camino team didn't think it should be done. On Tiger, cmd-space opens the Spotlight search bar. Ctrl-space does nothing in most cases as I mentioned in bug 160782.

I forgot to check the product of bug 160782. Anyway, most users don't find/need Ctrl+Space shortcut.

It's interesting. I noticed the missing feature to open the context menu while working on bug 403602. In that case you aren't able to control a selected download. Running different tests within normal browser windows show that the shortcut is working. Is it a local issue for the download manager? We should have a possible way to open a context menu with the keyboard only. I still haven't found an OS X wide global shortcut (if there still exists one).

Sorry for my misleading last comment, but the shortcut ctrl+space doesn't work in Firefox 3 at all. Because a huge amount of features are only accessible via contextual menus users without a mouse can't easily access them. Following dialogs/windows are affected: * Download manager (no access to any of the commands, e.g. pause, resume or cancel) * DOM inspector (no access to selected node commands) * Add-ons panel Josh, can this shortcut be re-activated without a huge amount of work?

This looks like a big regression for Mac users. Why minused?

Josh, can you take a look at this?

Josh, you need to call maybeInitContextMenuTracking after you send the context menu event to Gecko (on browsers that use non-native context menus, as we now do from menuForEvent: (after my patch for bug 416455)): nsCOMPtr<nsIPrefBranch> prefs = do_GetService(NS_PREFSERVICE_CONTRACTID); if (prefs) { PRBool useNativeContextMenus; nsresult rv = prefs->GetBoolPref("ui.use_native_popup_windows", &useNativeContextMenus); if (NS_FAILED(rv) || !useNativeContextMenus) [self maybeInitContextMenuTracking]; } I'm also puzzled by the differences between how you initialize the context menu event in this code and how it's done in menuForEvent:. Should the menuForEvent: code be changed to be more like this code? I should probably test this. But I'll wait until you post a revised patch.

Nice catch, thx

Josh, I've already found one problem -- I always get a beep when I use ctrl-space (testing on OS X 10.4.11). So far everything else seems to be fine, though (I've always gotten the appropriate context menu, and it's always been usable, either with the mouse or the keyboard).

Another oddity (probably not a problem, again testing on 10.4.11): Do Minefield : About Minefield and press ctrl-space. A context menu will appear containing the following choices: Undo Cut [greyed out] Copy [greyed out if nothing selected] Paste [greyed out] Delete [greyed out] Select All "Select All" selects part (though not all) of the text in the window. Once it's been selected, Copy is no longer greyed out and copies it to the clipboard. The odd thing is that neither right-click nor ctrl-click raise a context menu when used in the About Minefield dialog.

No beep on OS X 10.5.2.

I'll check out the beeping on 10.4. The selection oddness in the about box is probably just something funny with the about box XUL.

There is really no need to go on processing that event after we have sent the context menu event, this bails after sending the context menu event and solves our 10.4 problems. This also includes a fix to insertNewline:. We shouldn't intercept that in doCommandBySelector:, we should just implement it correctly in the insertNewline: method. I had Masayuki test with Korean IME and it works fine.

Comment on attachment 306917 [details] [diff] [review] fix v2.1 I haven't tested this (and in any case I'm not sure how to test the IME stuff). But it sounds like others have already given this adequate testing, and I can't see anything wrong with the code.

+ if (!mKeyPressSent && (!geckoEvent.isChar || geckoEvent.isControl) && Why is this part of this patch? > This also includes a fix to insertNewline:. We shouldn't intercept that in > doCommandBySelector:, we should just implement it correctly in the > insertNewline: method. I had Masayuki test with Korean IME and it works fine. This should be a separate patch too, or better still a separate bug.

Separate out the other patch and get rid of the extra line.

landed on trunk

Thanks Josh! Works great with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b5pre) Gecko/2008030404 Minefield/3.0b5pre ID:2008030404. There are some follow-up bugs introduced by this one which I will mark as depending. Verified. Is TM mozilla1.9 the correct one? It looks like there is no other one available right now.