227525 - file -> open file menu item does not work when no windows open

Status: RESOLVED FIXED

(Firefox :: Menus, defect)

Description

[Jonathan Louie]

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

Comment 1

[Mark E.]

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.

Comment 2

[Noemi]

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.

Comment 3

[Mark E.]

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.

Comment 4

[Jonathan Louie]

download manager menu problems are bug 228615, fyi.

Comment 5

[Mark E.]

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...

Comment 6

[HARUNAGA Hirotoshi]

I think this is a dup of Bug 83313.

Comment 7

[Jonathan Louie]

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

Comment 8

[HARUNAGA Hirotoshi]

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

Comment 9

[Tracy Walker [:tracy]]

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.

Comment 10

[Noemi]

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.

Comment 11

[Jo Hermans]

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

Comment 12

[HARUNAGA Hirotoshi]

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

Comment 13

[Asaf Romano (gone)]

fix in bug 273217.

Comment 14

[Asaf Romano (gone)]

fix in bug 273217.

Comment 15

[Jonathan Louie]

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.

Comment 16

[Asaf Romano (gone)]

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

no.