WADA:World Anti-bad-Duping Agency Reporter
	Description • 10 years ago

Customized shortcut on Mac OS X blinks menu but does not invoke command of <menuitem>, unless menu is opened. If menu is opened, customized shortcut invokes command of <menuitem>. If menu is closed, predefined shortcut  invokes command of <key>.

	WADA:World Anti-bad-Duping Agency Reporter
	Comment 1 • 10 years ago

This bug is meta bug for tracking bug reports on phenomenon of "Customized shortcut on Mac OS X doesn't work as expected".
This bug is meta bug for tracking bugs, so, please don't add comment on specific problem, symptom, phenomenon, or comment of "complaint".

	WADA:World Anti-bad-Duping Agency Reporter
	Comment 2 • 10 years ago

When I searched bugzilla.mozilla.org for phenomenon of "even when user assigned new shortcut to Firefox Menu/Quit Firefox, Command+Q still terminates Firefox", which was reported a forum lately, I found that all of bug 457973, bug 515395, bug 624881, bug 646362, bug 938303 were closed as dup of bug 429824, so I was very surprized.
  -  Original report of bug 429824 comment #0, has following special characteristics.
         Refers to symptom of "customized shortcut does not invoke command of <menuitem>" only.
         No description about important/common "menu blinks".
         Keyboard Shortcut: ⇧⌘A is already assigned to Add-ons menu by default.
         i .e. Phenomenon stated in bug 429824 comment #0 is already WORKSFORME.
   - In Firefox Menu/Quit Firefox(Command-Q) case,
      phenomenon of  "customized shortcut does not invoke command of <menuitem>" doesn't occur.
How can bug 457973, bug 515395, bug 624881, bug 646362, bug 938303 be dup of bug 429824.
Further, I found that Bug 316459  and Bug 328746 for Firefox 1.5 was closed as dup of bug 429824.
In both bug, bug reporter says;
    Before menu click after shortcut assignment, customized shortcut does not invoke command of <menuitem>.
    However, after menu click,  customized shortcut does invoke command of <menuitem> as expected.
How can different symptom in diferent(older) Firefox Release be dup of bug 429824?

I've reopened following bugs which were once wrongly/badly closed as dup of this bug(Bug 429824), in order to check similarities/differences among these bug reports. (i.e. I've removed these bugs from dup chain of Bug 429824 for proper problem analysis).
    (a) Zoom(no assigned shortcut) case :
          Bug 316459  for Firefox 1.5 : Oldest bug which was once closed as dup of this bug.
             Reported phenomenon in Firefox 1.5 was : New shortcut doesn't work until menu is clicked.
             Symptom-a-1 : Before first menu click after shortcut assignment, new shortcut doesn't invoke action of menu.
             Symptom-a-2 : After first menu click after shortcut assignment, new shortcut does invoke action of menu.
          Bug 827652  for Firefox 17  : Newest bug which was once closed as dup of this bug.
             Symptom-a-3 : 
                  Symptom-a-3-1 : If menu is closed, new shortcut doesn't work(==command is not invoked).
                  Symptom-a-3-2 : Menu blinks instead.
             Symptom-a-4 : If menu is opened, new shortcut does work(==command associated to menuitem is invoked).
    (b) Menu which has assigned shortcut other than  "Quit Firefox" . Minimize(Cmd-M) and Download(Cmd-J)
          Bug 316459  for Firefox 1.5 : Minimize(Cmd-M) : Bug 316459 reported both Zoom(no shortcut) and Minimize(Cmd-M) 
          Bug 328746  for Firefox 1.5 : Download(Cmd-J) : Oldest bug which was once closed as dup of this bug.
             Newly assigned shortcut :
                Symptom-a-1  always occurs on newly assigned shortcut
             Originally assigned shortcut :
                Symptom-a-5 : Original shortcut always invokes command associated to <key>
    (c)  Quit Firefox(Command-Q) case
          Bug 938303 and bugs which are now placed in dup chain of  Bug 938303. 
          Report after Firefox 3.0 only..
             Newly assigned shortcut :
                 Symptom-a-3 doesn't occur in Quit Firefox(new shortcut) case. Newly assigned shortcut always works.
             Originally assigned shortcut (Command-Q) :
                 Firefox 1, Firefox 2      :  Symptom-a-5 doesn't occur. Original shortcut does do nothing.
                                                        i.e. user could kill Command+Q by new shortcut assignment.
                 Firefox 3 to Firefox 29 :  Symptom-a-5 always occur, then Firefox terminates by Command-Q.
                                                        i.e. user can't kill Command+Q by new shortcut assignment.
                 After fix of Bug 938303 : Command-Q does do nothing, so user can press Command-Q freely, safely.
Because of Symptom-a-4  and Symptom-a-5 exists, following occurs when "Swap two shortcuts" is executed.
    (d)  "Swap two shortcuts" case
           If menu is opened, Symptom-a-4 always occurs.
           If menu is closed,   Symptom-a-5 always occurs.

Any bug report which was once closed as dup of this bug has one or more following symptoms.
    Symptom-a-1 in Firefox 1.5, Symptom-a-2 in Firefox 1.5,
    Symptom-a-3-1, Symptom-a-3-2, Symptom-a-4 after Firefox 3 (excluding Quit Firefox)
    Symptom-a-5 in any Firefox releases (excluding Command-Q for Quit Firefox in Firefox 1 and Firefox 2)

	WADA:World Anti-bad-Duping Agency Reporter
	Comment 3 • 10 years ago

Bug 938303 is for Firefox Menu/Quit Firefox(Command+Q) only.
   Because of Command+Q, symptom of "predefined shortcut still invokes command of <key> even after shortcut change"
   is critical for Mac user, because W is located at just right of Q on QWERTY keyboard.
   So, command attribute of <key key="Q" modifier="accel"> was removed in Firefox 1 and Firefox 2.
   However, command attribute of <key key="Q" modifier="accel"> was set from Firefox 3 by mistake.
  So, command attribute of <key key="Q" modifier="accel"> will be removed by Bug 938303 again.
Same "predefined shortcut still invokes command of <key> even after shortcut change" will occur on any predifined shortcut, because all <key> definitions which is referred by <menuitem> has currently has "command or oncommand" attribute.

	WADA:World Anti-bad-Duping Agency Reporter
	Comment 4 • 10 years ago

Question about difference between "Quit Firefox(Command-Q)" and "ZOOM(no shortcut)"/"Minimize(Command-M)".
   Why newly assigned shortcut works as expected in "Quit Firefox(Command-Q)"
   but it produces "menu blink only" in "ZOOM(no shortcut)"/"Minimize(Command-M)" if menu is not opened?
   Difference of script invoked by command in <menuitem>?

	WADA:World Anti-bad-Duping Agency Reporter
	Comment 5 • 10 years ago

By dependency tree, history is seen.
   1. Two bug reports for Firefox 1.5. Symptom is different from Bug 429824 and its all dups.
   2. Bug 429824 for Firefox 3 RC1. All reports are duped to this bug, except .following.
   3. Oldest/Newest report after Bug 429824 for ZOOM(no predefined shortcut, so simplest case). 
        Bug 435863 : for Firefox 3 RC1
        Bug 827652 : for Firefox 17
   4. Bug 938303 (Quit Firefox/Command-Q case). Quit Firefox case is different from oter case.

	WADA:World Anti-bad-Duping Agency Reporter
	Comment 6 • 10 years ago

Simple/easy workaround of "<menuitem> with predefined <key>" case.
    Change Firefox's <key> definition. Command-M to Option+Shift+Z example.
           <menuitem ... key="xxx"> is defined for menu.
           <key id="xxx" command="..." key="M" modifier="accel"> (accel == command on Mac OS X)
     => <key id="xxx" command="..." key="Z" modifier="option shift">
Simple/easy workaround of "<menuitem> without predefined <key>" case.(ZOOM is an example).
    Add Firefox's <key> definition, and pu it in <menuitem>. Option+Shift+Z example.
           <menuitem id="yyy"  ...   label="YYY" command="command_for_YYY"> 
     => <menuitem id="yyy"  ...   label="YYY" command="command_for_YYY" key="id_of_added_key"> 
     Add <key id="id_of_added_key"  key="Z" modifier="option shift" command="command_for_YYY">

This is pretty easily done by user defined toolbar button by "Custom Buttons" or "PrefBar" extension.
For example.
   Change Command-M to Option+Shift+Z.
   var elem=docement.getElementById("xxx");elem.setAttribute("key","Z");elem.setAttribute("modifiers","option shift");

	WADA:World Anti-bad-Duping Agency Reporter
	Comment 7 • 10 years ago

Both Oldest/Newest report after Bug 429824 for ZOOM(no predefined shortcut) reported following symptom.
.       Bug 435863 : for Firefox 3 RC1
        Bug 827652 : for Firefox 17
When new shortcut which is not used by anyone is assigned to Zoom, and after new shortcut assignment is shown in menu,
    (1) When menu is not opened,
          (1-a) command specified in <menuitem> is not invoked.
          (1-b) instead, menu is blinked.
    (2) When menu is opened,
          command specified in <menuitem> is always normally executed.
Many of currently duped bugs to Bug 429824 reported all these symptom for newly assigned hortcut, although many of bugs to Bug 429824 reported (1-a) only.

i.e. Nothing is changed or improved since Firefox 3 RC1.

	WADA:World Anti-bad-Duping Agency Reporter
	Comment 8 • 10 years ago

1. Install "Custom Buttons" or "PrefBar" extension.
2. Add new button
3. Put this script in "Code"
4. Customize Toolbar, move button to Toolbar
5. Click the button
    => Shortcut for menu_find(Edit/Find) is changed from Command+F to Command+Shift+X

	WADA:World Anti-bad-Duping Agency Reporter
	Comment 9 • 10 years ago

"Adding new <key> for Zoom case" is supported.

	WADA:World Anti-bad-Duping Agency Reporter
	Comment 10 • 10 years ago

> When new shortcut which is not used by anyone is assigned to Zoom, and after new shortcut assignment is shown in menu,
>     (1) When menu is not opened,
>           (1-a) command specified in <menuitem> is not invoked.
>           (1-b) instead, menu is blinked.
>    (2) When menu is opened,
>          command specified in <menuitem> is always normally executed.

"Keyboard shortcut change of a menu via System Preferences -> Keyboard on Mac OS X" is currently similar to "accesskey change" in Fireox?
In Win/Linux, "string shown at right of menu text in menuitem" is acceltext of <menuitem> which is obtained via <key> definition pinted by key attribute of <menuitem>. And "command execution via key binding/shortcut/hotkey" is always executed via "<key>" definition.

If so, above phenomenon is;
   When new shortcut set via "System Preferences -> Keyboard" is pressed,
    if menu is closed,  OS X highlights menu, and Firefox does do nothing because "key defined in <key>" is not pressed.
    if menu is opened, by pressing new shortcut, the menuitem is selected, and command associated the menuitem is invoked,.
Note: 
It can not explain why "new shortcut for Firefox Menu/Quit Firefox" works.
"Firefox Menu" is different from other menus and is special?

	WADA:World Anti-bad-Duping Agency Reporter
	Comment 11 • 10 years ago

(In reply to Josh Aas (Mozilla Corporation) from bug comment #3)
> Note that if user-defined shortcuts are a big enough deal for Mozilla Mac OS X users it wouldn't be very hard to write an extension that allowed it.

Sample script attached to commen #9 is perhaps an example of such extetion.
It's pretty simple.
  If <menuitem> has key attribute, modify hotkey assigned to <key>.
  If <menuitem> doesn't have key attribute, add <key> for new hotkey, and put it in <menuitem>. (Zoom case)
This is pretty standard "user customization by changing XUL element definition".
I don't think "shortcut change by OS X" is so important.
But "kill Command+Q by shortcut change in OS X" is nedded for many Mac OS X users. This is reason why I reopened bug 938303 and other bugs with removing them from wrong dup chain of bug 429824.


(In reply to Josh Aas (Mozilla Corporation) from bug 429824 comment #2)
> Unfortunately I don't think this feature is compatible with the way Gecko
> works now and we're going to have to live with the regression for now. The
> reason it worked before is similar to the reason we didn't suffer from bug
> 78414 for a long time (see bug 428047). We might be able to work out a
> solution to this, but any solution is going to involve another very risky
> change to the way our key event handling works on Mac OS X and we simply
> cannot do that for Gecko 1.9 any more.

Josh Aas, imcompatibe so deeply or hardly?
If "associated key binding to <menuitem>" already exists, "what is needed upon shortcut change by OS  X" is merely "hotkey assignment change of <key>" in addition to "acceltext change of <meueitem>", isn't it? 
"hotkey assignment change of <key>" is so risky in key event handling of Gecko?

	WADA:World Anti-bad-Duping Agency Reporter
	Comment 12 • 10 years ago

(In reply to Josh Aas (Mozilla Corporation) from bug 429824 comment #2)
> Unfortunately I don't think this feature is compatible with the way Gecko works now and we're going to have to live with the regression for now. 

Josh Aas, if absolutely imcompatibe, why new shortcut key works as expected if "Firefox Menu/Quit Firefox"?
As clearly stated in bug 646362 comment #0, which is dup of bug 938303, symptom of  "Firefox Menu/Quit Firefox" case is;
> Actual Results:  
> Both the default and the new overridden keyboard shortcut will work.
> Expected Results:  
> Firefox quits only on the new, overridden shortcut and the old default shortcut does nothing.

	WADA:World Anti-bad-Duping Agency Reporter
	Comment 13 • 10 years ago

philippe, do you see problem of bug 429824 in "Firefox Menu/Quit Firefox(Cmd-Q)" case?

	Josh Aas
	Comment 14 • 10 years ago

I am not really working on this stuff any more, and can't really recall all of the background info here. Steven Michaud should probably make any new decisions here.

	WADA:World Anti-bad-Duping Agency Reporter
	Comment 15 • 10 years ago

http://mxr.mozilla.org/mozilla-central/source/widget/cocoa/nsMenuBarX.mm#945
"Firefox Menu and its Submenus" looks processed by native code. Other menu/submenu are perhaps processed by general code. This is perhaps difference between "Quit Firefox(Command+Q)" case and "Minimize(Command+M) or Zoom(no shortcut)" case.