1. Open Cocoa Firefox 2. Close initial window with mouse 3. Hit command-w Since no windows are open at this point, command-w should be disabled. However, it does not get disabled until you show the menu on screen. If for step 3 you try to use the mouse you won't have this problem because the menu is shown on the screen. We should definitely fix menu updating, and maybe also not crash even if the bad command does get sent.
Note this was always an issue in Carbon widget, AFAICT the command isn't fired.
Every time you open a menu, all items are recreated, so it may be due to the fact that the command handlers do not point at the right items then? (BTW, DOM inspector on mac seems to be broken where the fundamental problem is in the way we tear down menus as soon as you turn your back on them; I debugged this a few months ago.)
Created attachment 225754 [details] [diff] [review] fix v1.0 When a menu item is initially created, its enabled state is pulled from its own DOM node, which is inaccurate until the state changes for the first time or the menu item is updated via the OnCreate handler. Since enabled state matters even when menus are not open, we should dig it out from the command content instead of the DOM node content when the nsMenuItem object is created.
Comment on attachment 225754 [details] [diff] [review] fix v1.0 Excellent!
Comment on attachment 225754 [details] [diff] [review] fix v1.0 sr=pink
fixed on trunk