since bug 204418 was closed, filing remaining problems as new bugs.

On Mac 10.3.2 (all updates including today's), with build: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6b) Gecko/20031218 Firebird/0.7+ I experience this issue ONLY when the downloads window is the ONLY open OR only active window. By only active, I mean for instance, if you minimize a rebular browser window, though it is still in the dock and open in the background, if the only remaining active window is the downloads, it happens too. If I have no windows open, the Cmd-N keyboard and pull-down menus have both been opening new windows as expected.

Mark - I think the problem is not the inability to open new windows with cmd-N, but to open a local file in a new window with cmd-O. Neither the keyboard shortcut nor the menu item work with no windows open, which means that if you want to open a file from disk, you have to first open a new window.

Well, I see that I read to fast. Nevertheless, the behavior I described does occur w/ respect to opening new windows when the download manager, or, the "find" dialog box are the only windows active...this may be connected, or, another bug...thanks for pointing out the difference, I was too quick to think I'd found a match.

download manager menu problems are bug 228615, fyi.

After reading what is there, and reviewing my own experience, I think they are related...thanks for the pointer to the post about the download manager, but this happens when any window other than a browser window is the only window open... the app must filter menus w/ context sensitive to windows open? Since those functions don't apply to the active window, they aren't executed....odd. but try it yourself, if Find, Download Manager, Preferences, (windows that aren't browsers) are open and the only ACTIVE window, then the commands won't open, so I think these behaviors are likely related...

I think this is a dup of Bug 83313.

would fixing bug 83313 fix this bug in firefox as well?

*** Bug 249766 has been marked as a duplicate of this bug. ***

Note that bookmarks manager doesn't display this problem because it has its own menu items. This is a dupe of 83313. Can all the Menu items (all but Firefox and probably File, so we can open a new window) be removed when the only Firefox window open doesn't have any menu items of its own? Shouldn't that happen when a window that doesn't have any menu items has focus, even if other Firefox windows are open? Similar to the behavior of the menu when Bookmarks Manager (three menu items) has focus.

Most Mac apps, when they don't have any windows open, leave the menus available, but gray out (make inactive) menu items that don't make any sense in that context (the same way that if there's nothing on the clipboard, the "paste" command is visible but not active in the menu). I think Camino does an excellent job of this for a browser - and it leaves some menu items active that you'd think require a window to make sense (e.g. Go->Home, or a bookmark in the menu), and when those are selected just automatically creates a new window. IIRC Safari does similar things, and even IE for Mac. It's how Mac users expect apps (and especially browsers) to behave at this point, and it probably doesn't make sense to break that expectation without a really good reason.

*** Bug 272461 has been marked as a duplicate of this bug. ***

*** Bug 278400 has been marked as a duplicate of this bug. ***

fix in bug 273217.

fix in bug 273217.

so the solution from bug 273217 was to disable file->open? it seems like you might want to open files when you have no browser windows open.

(In reply to comment #15) > so the solution from bug 273217 was to disable file->open? no.