Hi, This is a bug report about an issue mentioned on the following support thread, which I was able to replicate: https://support.mozilla.org/en-US/questions/944870#answer-394987 Steps to Replicate: 1. Open Firefox. 2. Click on the Window menu. 3. If there is already a shortcut set for Window > Zoom, skip to step #10 Otherwise, follow the next steps to create a shortcut: 4. Open System Preferences. 5. Go to Keyboard > Keyboard Shortcuts > Application Shortcuts 6. Click the + icon to create a new shortcut. 7. For Application, choose Firefox. 8. For Menu Title, type "Zoom" 9. For Keyboard Shortcut, choose a unique combination (I chose Cmd+Shift+Ctrl+M) Finally: 10. Press the existing/newly created shortcut for Window > Zoom Expected Results: When the shortcut is pressed the first time, the Firefox window should maximize. When the shortcut is pressed a second time, the Firefox window should return to its normal size. Actual Results: When the shortcut is pressed, the Window menu is highlighted, but nothing happens. Observations: 1. Firefox behaves as expected when clicking directly on Window > Zoom menu. 2. The shortcut for Window > Minimize works correctly. Please let me know if there is any additional testing that I could do to help pinpoint this issue, or if there are any comments or suggestions. Thanks!!
Another observation: When the Window menu is showing, the 'zoom' shortcut works. When the menu is hidden, it doesn't.
This is a dupe of bug 533318, but that bug was duped to the more general bug 429824, so duping this one to that one too.
Re-open, in order to check similarities and differences among following cases: key binding Major menu Sub menu <key> Bug 938303 Command-Q Firefox Quit Firefox Q,accel, id = key_quitApplication, command = cmd_quitApplication Bug 316459 Command-M Window Minimize M,accel, id = key_minimizeWindow, command = minimizeWindow This bug N/A Window Zoom <menuitem command="zoomWindow"/> Bug 328746 Command-J Tools Download J,accel, id = key_openDownloads, command = Tools:Downloads
Setting dependency to Bug 938303 for ease of analysis and tracking.
(A) Test in Bug 316459 is for following cases; (Report for Firefox 1.5) Assign Cmd-Opt-M for Window Minimize, which has key binding of Cmd-M in Firefox Assign Cmd-M for Window Zoom, which has no key binding in Firefox And, once "Window" menu was clicked, both new shortcut assignment worked well. > 4) Click on "Window" menu. > 5) Remove focus from Window menu by clicking on Firefox window. > 6) Confirm shortcuts now work: > Press Cmd-M. Window zooms. > Press Cmd-Opt-M. Window minimizes. (B) Bug 938303 is for Firefox menu, Quit Firefox, Cmd-Q. In this case, newly assigned keyboard shotcut works pretty well in Firefox 25 and Firefox 29. Problem is "Cmd-Q still invokes Quit Firefox". User should be pretty careful when he tries to press "Cmd+W". There is no problem of "newly assigned shortcut doen't work" nor "menu blinks" in this case. To Ralph Daub [:rdaub] (bug opener): "Cmd+Shift+Ctrl+M" doesn't work even when "Window menu" is intentionally opened? "Blink of menu" occurs even when "Window menu" is already selected at menu bar?
Sorry, following was already reported by comment #1. > Another observation: When the Window menu is showing, the 'zoom' shortcut works. > When the menu is hidden, it doesn't. I knew such comment in a bug, but I forgot "the comment was in this bug" :-) By duping to bug 429824, all valuable and important information/observations by this bug was lost... To bug opener and all proble reporters in this bug: Phenomena is same in latest Firefox? (as of today, Firefox 29.0.1). Do you see same "blinking menu" and "When the menu is showing, the shortcut works" in Cmd-M(Minimize) case, Cmd-J(Download) case, aand Cmd-Q(Quit Firefox)? case
Quick summary of phenomena in Firefox 3 and later. (1) Phenomena reported by this bug. (1-1) If menu for the new shortcut is not opened, menu is blinked when the new shortcut key is pressed. Exception of this: New shortcut for Firefox menu/Quit Firefox works, even when Firefox menu is closed or is not selected at menubar. This indicates that "action of executed script by oncommand=... via command=..." is relevant to problem. (1-2) If menu for the new shortcut is opened, the new shortcut works. This indicates that problem is in "menu update process". (2) If default key binding is defined by <key>, when menu is not opened, the default key binding invokes action for the menuitem via <key command=...> definition. => Bug 938303 started to occur from Firefox 3.0. This is reason why patch for Bug 938303 resolves problem of Bug 938303. (3) When swap of two already defined shortcuts are executed; (3-1) When menu is closed, because of (2), original action is executed by two shotcuts. (3-2) When menu is copened, because of (1-2), newly assined action to the shortcut is executed.
(In reply to jblz from comment #1) > Another observation: When the Window menu is showing, the 'zoom' shortcut works. > When the menu is hidden, it doesn't. This is "menu handling problem when shortcut is pressed", isn't it? http://mxr.mozilla.org/mozilla-central/source/widget/cocoa/nsMenuBarX.mm#361 > 361 // To work around bug 722676, we sometimes need to delay making mNativeMenu > 362 // the main menu. This is an Apple bug that sometimes causes a top-level > 363 // menu item to remain highlighted after pressing a Cmd+key combination that > 364 // opens a new window, then closing the window. The OS temporarily > 365 // highlights the appropriate top-level menu item whenever you press the > 366 // Cmd+key combination for one of its submenus. (It does this by setting a > 367 // "pressed" attribute on it.) The OS then uses a timer to remove this > 368 // "pressed" attribute. But without our workaround we sometimes change the > 369 // main menu before the timer has fired, so when it fires the menu item it > 370 // was intended to unhighlight is no longer present in the main menu. This > 371 // causes the item to remain semi-permanently highlighted (until you quit > 372 // Firefox or navigate the main menu by hand). If predefined shortcu by key binding(<key key/modifiers = Shortcut command="...">), Firefox don't touch. If manually assigned shortcut, menu is touched via <menuitem> definition or setting. <menuitem key="id of key element, or shortcut passed from OS if customized" command="...">. When menu is closed : If key binding defined by <key>, it's processed via <key>, so Fireox doesn't touch menu. If custmized shortcut, it's processed via <menuitem>, Firefox touches menu. So contention with OS occurs. When menu is opened : In any case, there is no need to highlight menu, because it's already opened, so OS does do nothing on menu. Then command defined in <menuitem> is normally invked via "newly assigned shortcut".
To Ralph Daub (bug opener) and jblz(comment #1 poster) : Can you check difference between "Window Menu/Minimize(Cmd-M)" and "Firefox Menu/Quit Firefox(Cmd-Q)" in recent Firefox? Can you check with Script attached to Bug 1015670 Comment #9?
Responding inline to the following questions, after testing on Firefox 30.0 - To Ralph Daub [:rdaub] (bug opener): "Cmd+Shift+Ctrl+M" doesn't work even when "Window menu" is intentionally opened? -> For me, this does not work. If I intentionally open the "Window menu" and press the combination of the newly-created Zoom shortcut (Cmd+Shift+Ctrl+M) the "Window menu" is deselected and disappears. Because of this, I'm renaming this bug again to remove "unless Window menu is opened. If menu is opened, shortcut works." "Blink of menu" occurs even when "Window menu" is already selected at menu bar? -> No. If I click on the "Window menu" to select it, and then press the newly-created shortcut for Zoom, the "Window menu" disappears as if I had clicked on it. To bug opener and all proble reporters in this bug: Phenomena is same in latest Firefox? (as of today, Firefox 29.0.1). -> Yes. This behavior is still happening on the version 30.0. Do you see same "blinking menu" and "When the menu is showing, the shortcut works" in Cmd-M(Minimize) case, Cmd-J(Download) case, aand Cmd-Q(Quit Firefox)? case -> No. Those default shortcuts (which were not created manually) work as intended, even if when the menu is not showing. This particular bug seems to be for manually created shortcuts. Can you check difference between "Window Menu/Minimize(Cmd-M)" and "Firefox Menu/Quit Firefox(Cmd-Q)" in recent Firefox? Can you check with Script attached to Bug 1015670 Comment #9? -> I'm sorry, I'm not sure how to check the difference of those shortcuts in recent Firefox or how to run the script. Please let me know if you have any questions or comments. Thanks!! - Ralph
> I'm not sure how to check the difference of those shortcuts Sorry for unclear question. Does new shortcut of "Cmd+Shift+Ctrl+M" work when Minimize(Cmd-M) and Quit Firefox(Cmd+Q)? Difference between "submenu in Window menu" and "submenu in Firefox menu". IIUC, new shortcut shouldn't work in Window/Minimize case as in Zoom(no predefined shortcut) case, and new shortcut should work in Firefox/Quit Firefox case as described in Bug 938303 because it's "Firefox menu". And, predefined shortcut(Ctrl+M or Ctrl+Q) should work always after shortcut change(this can't be checked by Zoom case because Zoom has no predefined shortcut).
Hi WADA, thanks for the clarification. I created new shortcuts for the menus you suggested, which had a previous default shortcut. The results are as follow - 1. Created a new shortcut (Cmd+Shift+Ctrl+M) for "Minimize" inside Window menu: The shortcut does not work, but the Window menu blinks. This is the same behavior as when I created a shortcut for "Zoom". The old shortcut (Cmd+M) still works. 2. Created a new shortcut (Cmd+Shift+Ctrl+M) for "Quit" inside Firefox menu: The new shortcut works. The old shortcut (Cmd+Q) still works as well.