48748 - The "tasks" menu should be called "Window"

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect)

Description

[Henri Sivonen (:hsivonen)]

Usually, the menu for switching between different windows is called "Window" or 
"Windows". Even though there might be a task associated with each window, "Tasks" as 
a menu name is a bit obscure compared to "Window".

Comment 1

[Peter "jag" Annema]

But it's not necessarily window switching. There are currently a number of menu 
items listed under Tasks:

--------------------
Navigator
Mozilla Mail
Newsgroups
Composer
--------------------
Address Book
IRC Chat
--------------------
Privacy and Security -> list of related managers)
--------------------
Tools -> list of tools
--------------------
[List of currently running tasks]
--------------------

Now, though it may be true that the last bit, "[List of currently running 
tasks]", is more commonly seen as a list of open windows, usually in its own 
menu ("Window"), all the other items in this menu deal not only with switching 
to that task, but more importantly starting that task if none is running yet. 
This is something which usually isn't found in a "Window" menu.

A new menu ("Window") could be added which just lists the currently open 
Mozilla/Communicator windows, or we could do what Communicator 4.7x does. In 
Communicator 4.7x, the "Tasks" menu is named "Communicator"(*) and has the list 
of open windows in a submenu called Window.

So, as to this bug, I would suggest "WONTFIX", and you could file a new bug with 
the above suggestion. Alternatively we can morph this bug.

(*) I assume it's called Tasks in Mozilla because Mozilla != Communicator and it 
is a better name for the menu than "Communicator" is anyway.

Comment 2

[Henri Sivonen (:hsivonen)]

All the menu items in the Tasks menu either open a window or switch to a window that is 
already open. It is not far-fetched to call the menu "Window". Contrary to what you are 
suggesting, there are quite a few well-known apps that include items that may open new 
windows in the Window menu.

So I wouldn't mark this WONTFIX.

Comment 3

[Peter "jag" Annema]

Can you give me a few examples of those "quite a few well-known apps that 
include items that may open new windows in the Window menu."? I don't seem to 
know them / use them.

Here's what I found on apps on my system:

Eudora 4.3.2, Acrobat Reader 4.0, Quicktime 4 and Microsoft Access 97 allow just 
window / MDI switching (in case of MDI there's also tiling, cascading, ...)

Internet Explorer 5.0 doesn't seem to have a Window menu or anything like it.

Microsoft Word allows me to switch between documents and also open a new one.

Netscape has starting a new Navigator/Messenger/Composer/AIM/etc. under 
Communicator and switching between windows under Communicator -> Window.

So, I don't really see a standard way of doing things here, but maybe I'm just 
looking at the wrong software :-)

Regardless, I don't think "Tasks" is an obscure name for a menu which allows you 
to start / switch to tasks. It also seems more generic to me than "Window", 
which is rather GUI specific.

Comment 4

[Henri Sivonen (:hsivonen)]

>Can you give me a few examples of those "quite a few well-known apps that
>include items that may open new windows in the Window menu."?

Adobe Photoshop 5.5, Adobe ImageReady 2.0, likely other Adobe authoring tools,
FreeHand 8, likely other Macromedia authoring tools and AppleWorks 5.0 have
palette management commands in the Window menu. IE 5 for Mac has commands for
opening Download Manager, Favorites and History in the Window menu. Anarchie has
commands for showing the transcript, the log etc. windows in the Window menu.
MT-NewsWatcher has commands for accessing filters and group list through the
Windows menu. And so forth and so on...

>It also seems more generic to me than "Window",

Sure, but it isn't a familiar term to users who are used to having a Window menu.

>which is rather GUI specific.

Mozilla has a GUI!

Comment 5

[Matthew T (active 1999-2002)]

Calling it `Window' wouldn't make much sense for most of the `Privacy & Security' 
sub-sub-(ugh)-items ... but then they don't make much sense anyway.

So I'd say it's a good idea (more discoverable), but it's dependent on getting 
rid of those sub-sub-items -- either by removing the need for them, or pushing 
them into the relevant dialogs as buttons. CCing Blake, who knows more than I do 
about that sort of thing.

Comment 6

[leger]

Reassigning from bdonohoe to hangas

Comment 7

[Peter "jag" Annema]

Henri, thanks for the list.

Re: the GUI part, I was thinking of using say a two way audio interface, but for
that a new locale could be created. A new chrome would most likely be needed
anyway.

This leaves us with just a simple naming question. Now, I feel "Windows" is
inadequate for the content, and I don't feel that just beacuse others are giving
it an inadequate name is a reason for us to do that too.

You argue along the lines of culture shock, that people will have trouble with
finding under "Tasks" what they're finding elsewhere under "Window". I sincerely
hope that after the first "Hmmm, where did they put this? Ah, here it is", they
will remember the next time.

I also wonder, when the UI specs for Mozilla were written, changing the word
"Communicator" to "Window" must've been thought of, but "Tasks" was chosen in
the end. Why?

Comment 8

[Matthew T (active 1999-2002)]

Window was probably rejected because in Netscape 6, `Tasks' is going to contain 
quite a lot of hardcoded bookmarks, which won't open their own Window (or switch 
to a different existing window). That's not an issue for Mozilla, though.

Comment 9

[Peter "jag" Annema]

Meaning that will never happen in Mozilla (as in, Bad Thing We'll Never Do)?

Otherwise, why limit Mozilla?

Comment 10

[hangas]

Well the answer is that we will not be changing this for N6.  I personally do not 
have an attachment to the word Tasks but the decision has been made that N6 will 
use Tasks.  Marking wontfix.  Mozilla might use a different word, or we might 
change it after N6, but not now.

Comment 11

[Matthew T (active 1999-2002)]

Sorry Paul, I think you forgot which bug database you were using for a moment. 
Reopening.

> Well the answer is that we will not be changing this for N6.

Not really relevant to Mozilla.

>                                                             I personally do not
> have an attachment to the word Tasks

Neither do I, but that's not relevant to Mozilla either. The question is, will 
the purpose of the menu be more obvious to Mozilla users if it is called `Window' 
than if it is called `Tasks'? A usability test to find this out could be done on 
a very low budget.

>                                      but the decision has been made that N6
> will use Tasks.

So go tell Bugscape.

>                  Marking wontfix.  Mozilla might use a different word,

In which case this bug should stay open, and not be resolved wontfix.

>                                                                        or we
> might change it after N6, but not now.

In which case the bug should be marked `Future', and not resolved wontfix.

Comment 12

[hangas]

Mathew as a mozilla bug this should stay open.  I am sending this to you so that 
you can help make it happen.

Comment 13

[hangas]

Sending to Mathew.

Comment 14

[Matthew T (active 1999-2002)]

So it's my decision now??? In that case, WONTFIX.

While Mac users might be used to having a `Window' menu which contains items for 
things other than open windows, users of other platforms are not -- except in MDI 
applications on Windows, and Mozilla is (thankfully) not an MDI application.

Henri, if you want to file an RFE for a separate `Window' menu on Mac OS -- which 
contains items for open windows (moving them from the Tasks menu), and a `Next 
Window' command (bug 53505) -- go right ahead. But for platforms other than Mac 
OS, the platform's built-in window-switching mechanisms are quite sufficient, so 
the location of the list of open windows does not need to be more obvious than it 
is now.

Comment 15

[Blake Ross]

vrfy wontfix

Comment 16

[Matthew T (active 1999-2002)]

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

Comment 17

[german]

What we have learned from Netscape 6 and the actual RTM is that "Tasks" was
technically the right term and indeed a suitable compromise, and I was
personally arguing in favor of it as well as I am sure you remember. But
observing how people used the actual RTM of time there was a smaller number of
people then expected that used this menu.
There are a number of precendents of other apps using windows to bring up
functionality of the product or switch to another part, such as many MS and
Adobe products, so this scenario should not be unfamiliar to our users.

Comment 18

[:deanis74]

Rename it in the commercial Netscape, then?

Comment 19

[Matthew T (active 1999-2002)]

German, before reconsidering this bug, I would like you to expand on the 
following aspects of your rationale for reopening it:
(1) how you learnt from Netscape 6 in particular that `Tasks' was technically
    the right term for the menu;
(2) what the difference is between `Netscape 6' and `the actual RTM';
(3) what the `RTM of time' is;
(4) a list of the `many' MS apps (other than those produced specifically for
    Mac OS, where bug 75546 applies) which use `Window' as a title for a menu
    in which most of the items are non-windowing functions;
(5) what you thought you were achieving by making almost identical comments in
    two bugs (this bug and bug 79476) within three minutes of each other;
(6) whether you agree with the supposition that users are not using this menu
    as much as `expected' (expected by whom?) not just because it has a
    non-obvious name, but also because its structure is generally borked (bug
    32502, bug 48860, bug 50494, etc.);
(7) to what extent your concerns would be addressed by renaming the menu as
    `Tools', which (IMO) more accurately covers the contents of the menu, and
    which is due to be implemented as part of bug 32502.

Comment 20

[Blake Ross]

The comment in the duped bug was:

"Improving usability of app and discoverability of items under this menu, change
name on top of menu from "Tasks" to "Window""

So to go along with Matthew's comments, I would like to know why users are more 
inclined to understand that they can access functionality other than window-
switching from this menu if you rename it to Window, from Tasks.

Comment 21

[german]

(1) usability testing before Netscape 6 ship
(2) Netscape 6 PR releases vs the actual final release
(3) a typo
(4) aside from all MS apps on Mac MS Word and Excel specifically let you either
create new windows from that menu or switch to open windows which is what this
was designed for. In addition most apps let users bring up certain types of
special windows.
(5) I was thinking about taking over the world. No seriously I was adressing a
different set of reporters and cc'd people and the new bug as well as the
original one (which we could not find at first, hence that new bug got filed)
(6) and (7) I don't agree, I think "Tasks" is a barrier to entry as much as
tools would be, we spec. received many comments that both had negative
connotations in terms 'work', 'unpleasant' etc.

In summary I strongy believe it's the right thing to do for our users for the
next release of Netscape 6.x

Comment 22

[hangas]

Marking bug nsbeta1+ sending to andreww with milestone 0.9.1

Comment 23

[:deanis74]

4. Word and Excel let you bring up what is essentially a duplicate of the
current window.  There are no functions in there that open a new tool.
7. Tools is a little more intuitive to me than Tasks.  Ask someone to give you
an example of a tool and you'll get a fairly consistent set of answers - hammer,
screwdriver, etc.  Ask for examples of a task and the answers will be all over
the map.

"In summary I strongy believe it's the right thing to do for our users for the
next release of Netscape 6.x"

So does this mean that it will be done for the NS commercial build only, and we
can take more time discussing what's best for Mozilla, perhaps taking in
feedback from the next release?

Comment 24

[Blake Ross]

Microsoft Word 2000 (on Windows) has these items in its Window menu:

New Window
Arrange All
Split
-----------
Window List

Ours currently has:

Navigator
Mail
Composer
Address Book
------------
Privacy and Security > (submenu with a bunch of different managers)
------------
IRC Chat
Tools > (submenu with access to history, js/java console, and import wizard)
------------
Window List


So if the functionality of the Window menu in apps like MS Word is the purpose 
of the Tasks menu as you say, we haven't been doing a very good job, have we? 
The menu in Word provides window-specific features and is deserving of the 
name "Window."  Ours provides everything under the sun with a window list 
tacked on at the end, and is deserving of the name "Tools/Window."  We're 
having trouble giving this menu the appropriate name because it's trying to do 
too many things at once.  And no, I don't think the solution is splitting it 
into two top-level menus; I think we should do what Matthew has suggested in 
other bugs, namely remove the window list on Linux and Winddows and turn it 
into a Tools menu (containing the items in 32502).

Comment 25

[andreww]

Attachment: patch to change tasks to "Window"

Comment 26

[andreww]

r= hangas, sr=hewitt 

Comment 27

[:deanis74]

Maybe I'm missing something here, but I don't see a consensus on this change.

Comment 28

[Matthew T (active 1999-2002)]

Ok then, fine. If you're going to reassign this bug away from me when I'm 
clearly not neglecting it, and if you're going to rush through this change 
without any sort of UI process, then this bug is Netscape only. You can 
maintain the fork, and you can work out what to do in your tree when bug 75546 
is implemented.

If this menu is renamed to `Window' in the Mozilla tree, without first moving 
all (or at least most) of the non-window-management items out of the menu, that 
will be treated as a usability regression. To have items such as `Allow Cookies 
From This Site' in a `Window' menu would be just absurd.

Comment 29

[andreww]

Patch checked into tree.

Just my 2cents, but perhaps it'd be a good idea to have some kind of UI pow-wow
for all persons concerned to iron out this an many other issues before the next
milestone so we can all work from understanding, and all feel like we are making
this the best browser possible.

Comment 30

[Ben Goodger (use ben at mozilla dot org for email)]

I agree with mpt and blake. mpt's solutions in other bugs have proposed 'Tools'
as an XP solution to the title for this menu. This is consistent with the
examples that blake etc have provided, and consistent with Internet Explorer,
which offers access to mail, etc. Tools is also probably the most generic and
correct name for the menu based on its contents. (unless anyone wants to suggest
better)

I think this patch went in a little too quickly. Both Matthew and Blake
expressed concern, and that should have been enough to put the brakes on as far
as mozilla is concerned. mpt has or is filing a bug on calling this item
"Tools," and if that indeed makes the most sense that is what should be chosen.
I'll let him add the relevant bug number(s) here. 

Please, let's not let Netscape's deadlines interfere with correctness. It's not
like fixing this correctly would have taken days of deliberation and discussion. 

Comment 31

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

What kind of bullshit is this, exactly?  The UI:DF owner has given objections
that nobody has responded meaningfully to, and yet you just went and slammed in
this patch against his-and-blake's wishes.  _After_ rudely taking the bug from him.

This isn't how we work around here.  I'm going to sleep right now.  Somebody
back this change out, sr=[e-mail].

Comment 32

[Matthew T (active 1999-2002)]

Renaming the menu as `Tools' is described as part of my 2000-11-11 spec for bug 
32502. If people want me to file a separate bug (a dependency of that one) for 
just the menu title, I'll do that.

Comment 33

[Scott Collins]

backed out, as per comments above

Comment 34

[Henri Sivonen (:hsivonen)]

I started a thread called "Reorganizing/renaming the Tasks menu" in n.p.m.ui.

Comment 35

[Blake Ross]

Reopening this due to backout.

Andrew, I know you were instructed to make this change by your manager (who is 
notorious for misunderstanding or ignoring Mozilla), but it still seems awfully 
arrogant and ignorant to say that we should discuss this UI -- that's what the 
rest of us were doing while you checked in.

Moving back to UI Design Feedback because Henri actually followed standard 
procedure and started a newsgroup discussion.  Hey, see how easy things are 
when we follow the rules?

Comment 36

[Blake Ross]

--> Matthew, because in the design stage this bug still belongs to him, and he 
was never consulted.  Netscape's beta requirements do not preclude Mozilla's 
processes.

(As a side note, isn't it just fitting that one of the people causing the 
trouble here has most notifications off, and isn't hearing anything about this?)

Comment 37

[Blake Ross]

So now we're back to square one: UI discussion.  Your basis for making this 
change was usability data and feedback collected from Netscape 6.0.  Why can't 
some of this data be published (if in very generalized terms)?  Specifically, I 
would be interested in knowing:

* What changed in the past few years such that millions of Netscape 4.x users 
understood that version's name for this menu -- "Communicator" -- but now they 
expect "Window".

* Or, if the millions of 4.x users didn't understand "Communicator", what kind 
of data led you to believe (incorrectly) that "Tasks" was the name they wanted.

* Why you're confident that "Window" will be -- after two other attempts -- the 
correct name.

* Why changing this menu's name from version to version until you get it right 
will *reduce* confusion among users.

In general, I think people are tired of this confidential usability info that 
seems to change from version to version.

Comment 38

[german]

* What changed in the past few years such that millions of Netscape 4.x users 
understood that version's name for this menu -- "Communicator" -- but now they 
expect "Window".
- Communicator is a Netscape tradmarked name no longer being used by this
product. As an aside, market research (yes this is based on confidential data)
showed us that Communcicator had a much worse recognition rate then either
Netscape (best) or Navigator (second best). Coomunicator literally had no
meaning to the majority of folks surveyed despite marketings best effort in the
late 90's to establish it as a household name of the suchnamed suite of net
applications. There is no legacy here worthy continuing for Netscape 6 and beyond.
* Or, if the millions of 4.x users didn't understand "Communicator", what kind 
of data led you to believe (incorrectly) that "Tasks" was the name they wanted.
* Why you're confident that "Window" will be -- after two other attempts -- the 
correct name.
I do not think there is much of an established base of Netscape 6 just yet. We
'll continue to learn from actual usage and refine the product as needed.
"Tasks' was the best educated guess at the time of the initial design based on a
relatively small sample of observations.

* Why changing this menu's name from version to version until you get it right 
will *reduce* confusion among users.
- It's a process called design iteration. Design gets actually gets iterated
beyond the launch of the product and into subsequent versions based on more and
more usage data is coming in. For example for the Netscape 6 browser there is a
certain of usage data after the product has been launched that we can track to
better understand usage patterns of the RTM version.
* In general, I think people are tired of this confidential usability info that
seems to change from version to version.
I understand your frustration but there is a lot of usage data that is strictly
AOL/Netscape confidential that I will not be able share with the public at all.
However as far as I know most Netscape client usability studies that involve
generic/public product parts can be attended folks outside Netscape.

Comment 39

[jglick]

I think it is difficult to find an accurate name for this menu item because 
it is sort of a mixed bag of stuff.  

What about breaking it into 2 separate menus? Yes, that means more menus but 
they would be more shallow and make it easier for people to find what they are 
looking for.

"Windows" could contain the window management type stuffs:

Navigator
Mail
IM (Netscape)
Composer
AB
-----
Open Windows


"Tools" could contain the more feature oriented stuff:

Privacy and Security (or list out the items in its submenu)
Tools submenu items

Comment 40

[Brendan Eich [:brendan]]

I like jglick's suggestion a lot.

Can't we all just get along?  Not with unilateral decisions and bug-grabbing.

/be

Comment 41

[Blake Ross]

I agree with Jennifer about the problem, but not the solution (see "And no, I 
don't think the solution is splitting it into two top-level menus..." in my 5/8 
comment ;-)

Actually, I can't speak for the other platforms, but Windows (and presumably 
Linux) shouldn't even have this window list (we have another bug on that).  The 
OS does quite a fine job of handling and switching between open apps.  (Future 
versions of Window, specifically Whistler, render the list even more 
unnecessary with the notion of app-specific taskbar groupings.)

Comment 42

[andreww]

Thanks for the understanding comments Blake.  I was only following orders
(shoots self in the head).  With the localization freeze and other things I was
under the impression that it was ready to go and change. And I can understand
how it seems to have been rushed to change.   

Comment 43

[Brendan Eich [:brendan]]

andreww: I don't know in which comments blake showed understanding (about your
boss making you do it?  That went out a long time ago as an excuse), but do not
ever again steal a bug assigned and currently owned by someone else.  That kind
of thing would not be tolerated if practiced by non-netscape.com contributors
against netscape.com owners.  It is not tolerated by [e-mail].

/be

Comment 44

[Brendan Eich [:brendan]]

andreww: sorry, I didn't View Bug Activity.  So hangas reassigned this and you
went along with that.  I guess I'll have to mail hangas directly, as blake says
he doesn't get notified on bug changes.  I'm this >< close to revoking his
editbugs capability.  Feel free to tell him to get in here and respond to the
reactions to his action.

/be

Comment 45

[hangas]

Yes I did assign this bug to andreww.  I had bug 79476 marked as a dup of this 
bug by mpt.  Since mpt had this bug open and he marked mine as a dup of this bug 
and there were comments in this bug suggesting that mpt still wanted to see this 
bug fixed I saw no reason to argue about which of the two bugs we fix.  I simply 
moved the bug to andreww to replace the one that mpt marked dup and gave it the 
nsbeta1+ that was on the dup bug.  You will notice that I was the original owner 
of this bug and gave it to mpt some time ago.

Comment 46

[jglick]

Since this menu is a mix of Window and Tools/Tasks related items, its 
tough to find a word that accurately describes its contents.

What about using the name of the application for this menu item?  Similar to 4.x 
 which used "Communicator".  "Netscape" for the NS version and "Mozilla" (or 
whatever is appropriate) for the Mozilla version?

Comment 47

[Matthew T (active 1999-2002)]

I regret to say that after that comment, I am even more concerned about 
Hangas's actions than I was before.

No, I did not `have this bug open'. It had been resolved as WONTFIX since
2000-09-21, for the reasons I gave then, and I still think those reasons are 
perfectly valid. The bug was reopened by German (2001-05-08), presumably at his 
manager's behest, with an explanation that I found very difficult to understand 
on both a grammatical and a logical level. (My earlier reopening of this bug
(2000-09-20) was not because I thought Henri's suggestion should be 
implemented, but because Hangas had resolved it on inappropriate grounds.)

Whether this bug was resolved or not does not affect in any way the fact that 
bug 79476 was an exact duplicate. I cannot help but think that Hangas filed the 
duplicate bug with malice aforethought, given that (as he has just pointed out) 
he had owned the original bug and obviously knew of its existence. Even if he 
had forgotten about it, a Bugzilla search for all words `tasks menu' in the 
summary would have found it (and the other bugs associated with the design of 
the Tasks menu) with no trouble at all.

No, there are not `comments in this bug suggesting that mpt still wanted to see 
this bug fixed'. Since I'd resolved the bug as WONTFIX, I cannot see how Hangas 
could be under that impression. Initially (2000-08-23) I said I thought calling 
the menu `Window' was a good idea, *provided that* the non-windowing-related 
items were removed from the menu. Since then, however, more and more
non-windowing-related items have been added to the menu, to the extent where 
(in an average scenario, say, two browser windows open) the windowing functions 
comprise less than 10 percent of the menu (2 items out of 28). To rename the 
`Tasks' menu as `Window' in such a circumstance would be akin to renaming the 
`File' menu as `Disk' on the grounds that 2 of its 15 items involve disk I/O.

And no, this bug should not have been reassigned, regardless of who owned a 
duplicate of it. I have no problem with bugs being reassigned away from default 
owners, if the default owners are placeholders (e.g. Browser-General, or HTML 
Elements), or if they are on sabbatical (e.g. Style System), or if they don't 
read their bugmail (e.g. Bookmarks), or if they don't respond to the bugs for 
months (e.g. Search). (Some of my bugs haven't been touched for months, but 
that's only because I'm still trying to catch up with the backlog I inherited 
from Hangas.) What I do object to, however, is when a `bug' in the User 
Interface Design component -- which is not a place for bugs to get fixed, but a 
place for user interface design issues to get answered and either wontfixed or 
reassigned -- gets taken away from me when I'm obviously giving it my full 
attention.

As for the design question itself, I agree entirely that `Tasks' is a poor name 
for the menu, but I think that -- given the menu's contents -- `Window' is 
considerably worse. Since this is a complicated issue which will inevitably 
involve the content and structure of the menus itself, a linear and already 
unwieldy Bugzilla report is probably not an appropriate forum in which to have 
this discussion. So I'd like interested parties to please participate in the 
n.p.m.ui thread instead. Thankyou.

Comment 48

[Matthew T (active 1999-2002)]

Ok. The following had broad agreement on n.p.m.ui (this is paraphrasing from a 
post by Henri Sivonen):
*   Split the `Tasks' menu into `Tools' and `Window', in that order.
*   If the `Window' menu is not present on all platforms, its visibility is
    controlled by a non-GUI pref so users can override it.
*   The `Window' menu should be visible on Mac OS (bug 75546).

The following was stuck in terminal disagreement:
*   Whether the `Window' menu should be visible on platforms other than Mac OS.
    -   I argue that it's unnecessary and confusing for the majority of users
        whose window manager UI works just fine for the small number of windows
        they have open; and that Internet Explorer doesn't have it.
    -   Several others argued that a `Window' menu should be included because
        it's more convenient when you have lots of Mozilla windows open; and
        that MS Office and MDI apps have it.

So I guess the lucky Ben gets to decide.

Comment 49

[Viswanath Ramachandran]

moving the implementation of this bug to Future. 

Comment 50

[timeless]

mpt: before someone decides to implement this...

{MacOS - or any wierd platform decides to show the menu while there are no 
windows open}
If there are no open windows, is the Window menu disabled?

Should the tools items still remain as a submenu?

ben: i know some manager just futured this bug, but would you please sign off 
in advance on as many of the decissions as you support to save any implementors 
agony later?

Comment 51

[Henri Sivonen (:hsivonen)]

I'm not mpt, but: The Cocoa framework doesn't disable the Window menu when no
windows are open. However, it looks like a bug and not like a deliberate
feature. (I think the Window menu should be disabled, if there are no windows
open. I'm assuming that none of the menu items makes sense when there are no
windows open.)

|Window|
Close Window            // Mac OS X (accel in File->Close)
Zoom Window             // Mac OS X (same as the title bar zoom button)
Minimize Window accel-M // Mac OS X
-----------------------
Bring All to Front      // Not applicable on Mac OS 8.5...9.1
Next Window opt/alt-tab // bug 53505 (but see also bug 55486)
-----------------------
{list of open windows}

Comment 52

[Matthew T (active 1999-2002)]

For Mac OS, what Henri said.

For the `Tools' submenu, we obviously couldn't have `Tools' > `Tools'. I think
that `History' would probably go into the top level; `Import Utility' would
become `Import ...' (and hopefully, one day, `Import/Export ...') in the `File'
menu; and lesser used stuff like the Cookie Manager, the Image Manager, and the
Script Console and Java Console would probably go into a `Utilities' submenu.

Comment 53

[Jason Kersey]

Quick question about this, Where are the top level component launchers going to 
live?  In windows or tools?  If they are going to be under tools, and windows 
will only have open window switching, then I really want to see it off on 
windows and linux, as I like the way my OS works.  If Windows will have the 
major components under it, I'd like to see the open windows put into an "Open 
Windows" menu or hidden entirely on windows and linux, for the same reason.  I 
find the open windows list to be stupid and ugly anyways, as it lists the title 
of the email, browser page, or composer page open.  If I have a mozillazine page 
open in an email message, the browser, and composer, there is no way to tell 
them apart, and that makes the menu utterly useless.   (4.x preceded the title 
of the menu with what type of window it was open in - Web Page, Email, Composer)

Comment 54

[Matthew T (active 1999-2002)]

> Where are the top level component launchers going to live?  In windows or
> tools?

Tools. (That's what they are.)

> If they are going to be under tools, and windows will only have open window
> switching, then I really want to see it off on windows and linux, as I like
> the way my OS works.

Right. Window switching is the job of the window manager, but Mac OS sucks at 
it (Classic and OS X in different ways), so we'd work around that using a menu.

Comment 55

[Boris Zbarsky [:bzbarsky]]

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

Comment 56

[Ben Goodger (use ben at mozilla dot org for email)]

I wouldn't call this a blocker for the 10899

Comment 57

[Blake Ross]

-> me

Comment 58

[Blake Ross]

fixed.

Comment 59

[Jamie Cho]

This is in regards to the next window functionality which apparently is going to be assigned to Apple-Option-Tab.

Mac OS X CoCoa application use Apple-` to switch between Windows (e.g. Mail). It does not seem like Carbon Windows do the same (in fact Apple-` acts the same as Apple-~ in the Finder).

I know this is late, but I just learned this trick from one of the Mac sites.

Comment 60

[sairuh (rarely reading bugmail)]

Tasks has now been refactored into the Tools and Window menus.

vrfy'd fixed, 2002.04.09 comm bits on linux rh7.2, win2k and mac 10.1.3.