249003 - Need workarounds for bug 21296 for the mac version of Firefox / All menus are inaccessible in some windows (Download / Theme / Extension Manager, Page Info)

Status: VERIFIED INVALID

(Firefox :: Menus, defect, P3)

Description

[Asaf Romano (gone)]

Since there is no upcoming solution for bug 21296 (Can't use Mac menu bar with a
menuless window in front), we should workaround it by adding few menus (mac
only) to the most problematic places, these are:
1. Download Manager
2. Extensions/Theme Manager
3. JavaScript Console
4. Page Info dialog

(The new menus will *replace* the current set).

Taking the download manager (bug 228615) for example, here is a first draft of
what menus should appear:

1.File
---New browser window, Open File.
2. Edit
---Disabled Paste/Cut, copy will copy the current download local file location,
and maybe others.
3. Current Download (or maybe other name). This will also follow Apple HIG
("Never provide a contextual menu command that is not also accessible through
the menu bar"), this menu will contain:
---Pause/Resume
---Open file
---Remove (or this should be in the "Edit" menu)
---Open containg Folder
---More info
4. Help
---Help Contents

In addition, the preferences menu item in the Application Menu should work.
-----------

Same principle for extension/theme managers.

I'm requesting blocking1.0mac?, if we pretend to release a mac-focused version,
we shouldn't have this kind of unexpected behavior.

Comment 1

[riscky]

A few things...
Bug 228615 is a dup of 245206, Bug 245206 is assigned and is set to block 1.0-mac.

This really should be marked as Wont Fix or Invalid as you shouldn't recreat
menus but dim items that don't have any meaning for the current window state...
ie no windows closed should be dimmed... not removed from the menu list.

Comment 2

[riscky]

Opps... sent the wrong info :( please disregard my previous comment.

I was writting about a few different things at once in one place...

I'll try again...

I don't think a new menu bar set should ever be created... when the window
states/tools change. The main app (firefox's) menu should stay the same and only
dim no logical choices for the top window. I've seen a few bugs stating that
case... but I can't find them.

Still I think this should be invalid or won't fix.

Comment 3

[Asaf Romano (gone)]

(In reply to comment #2)
> Opps... sent the wrong info :( please disregard my previous comment.
> 
> I was writting about a few different things at once in one place...
> 
> I'll try again...
> 
> I don't think a new menu bar set should ever be created... when the window
> states/tools change. The main app (firefox's) menu should stay the same and only
> dim no logical choices for the top window. I've seen a few bugs stating that
> case... but I can't find them.
> 
> Still I think this should be invalid or won't fix.

1. As I already said, Apple HIG: "Never provide a contextual menu command that
is not also accessible through the menu bar", this what happens on OS X, and
waht we do? provide these commands (Open Containing Folder, Properties) through
the contexual menu only
2. You have to choose between (1) set of not related menus that doesn't work (2)
set of relevant useful menus that does work... IMO the second option is
better... :-)

Comment 4

[riscky]

As for 1. Apple doesn't follow the Apple HIG, take a look at the various
programs apple gave the brush metal look to... but you can see a better, and
related example of this when you look at Safari’s download manager. Select a
download; contextual menus give you open, show in finder, copy address, and
remove from list of those the only one replicated some place else, that I know
of, is show in finder.

2.) The loss of drop down menus (not work able menus) only effects the download
manager, and only when it is the front most active window. When all current
downloads finish, drop down menus reappear (but functionality is still missing).
Until bug 245206 is fixed (and should be by 1.0-mac) your still not going to
have any functionality with or without a new menu layout. I’m left to wondering
this: Do you revert back to the old style menu layout once the download
finishes? Why would it be better to create a new menu set instead of fixing the
old one, and why would that happen first? Why wouldn't the new set suffer the
same problems as bug 228615?

Also why not request bug 228615 block 1.0mac?

Comment 5

[Peter da Silva]

Why not make the dialog windows regular windows on Mac OS X, with their own menus?

The reason for making the context menus regular menus as well is that there's
haxies and input managers that let you assign command sequences to regular menu
items, it would be nice to be able to use them with Firefox.

Comment 6

[kaldari]

>Why not make the dialog windows regular windows on Mac OS X, with their own menus?

Regular windows in Mac OS X don't have menus.

Comment 7

[Asaf Romano (gone)]

(In reply to comment #6)
> >Why not make the dialog windows regular windows on Mac OS X, with their own
menus?
> 
> Regular windows in Mac OS X don't have menus.

ah!? On OS X, *every* window has menus

Comment 8

[Simon Fraser [no longer active]]

> ah!? On OS X, *every* window has menus

No. On Mac OS X, no window has menus. The menus are at the top of the screen in
the menu bar, and are mostly common to all windows.

Comment 9

[riscky]

Just to add my two bits on this OS X no window has menu thing (in hopes it might
help Peter and Asaf) ... Simon it techinically correct... when I first read
comment #5 the first thing that popped in my head was Windows... but when I
started to think about it the Finder does have the tool bar that (as do many
apps) that may act or appear menu-bar-like.

However tool bars are local to the window, while menu bars are global to the
aplication.

Comment 10

[Peter da Silva]

We're not talking about toolbars here, we're talking about menus. On Mac OS X,
all windows have menus at the top, no windows have menus on the window itself.

Possibly a related problem is dialogs that don't have a title bar. They really
should if they're not sheets.

This should really be fixed in the Mac OS X specific code, one way or another,
with dialogs copying their parent's menus or providing a minimal global menu
(Firefox, File, Window, Help) they use if there isn't one specified.

Comment 11

[Phil Ringnalda (:philor)]

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

Comment 12

[Asa Dotzler [:asa]]

This or bug 21296 needs a fix for 1.1. Can you look into it?

Comment 13

[Asaf Romano (gone)]

note, there is already a better solution in bug 239218.

Comment 14

[Asaf Romano (gone)]

-> INVALID, see bug 239218 instead.