Open Bug 65121 Opened 24 years ago Updated 4 years ago

Remove File|Exit and replace with File|Close

Categories

(SeaMonkey :: UI Design, defect)

Product:
SeaMonkey
Component:
UI Design
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

People

(Reporter: tpowellmoz, Unassigned)

References

Details

(Keywords: dataloss, platform-parity, Whiteboard: [p-ie/win] [2012 Fall Equinox]) 

The File|Exit menu item (or File|Quit on Mac) as currently included in Mozilla
causes data loss, annoyance, and confusion. Windows users have been trained for
years that the bottom item on the left-most (usually File) menu closes the
current window. That this item should shut down entirely different apps is
completely unexpected. (Browser, email, address book, manage bookmarks, and
composer are not the same app; they are designed for quite different tasks and
are used independently.)

I cannot think of a case when I would want the File|Exit command on Windows.
What I expect as a user is that if I close all windows of an application the
application exits. (This is one of the things that most baffles Windows users
when using a Mac.) I would never want to close all the windows of a browser at
once, let alone all the Mozilla-based apps.

Yes, I know this behavior has gotten a great deal of discussion, particularly in
bug 39057 "File > Quit needs a warning dialog" (and its many duplicates). The
second comment in that bug was from Blake Ross saying that he planned to log a
bug exactly like this one. If it has already been logged, I can't find it, so
I'm logging it here.

Just to be completely clear: Close should replace Exit in the left-most menus
(File) on all Mozilla windows. It should be the bottom menu item on the
left-most menu. The behavior should be to close the current window, exactly like
clicking the close X button on the top right of the menu.

There is no user need for a global "close all" or "exit all Mozilla apps" menu
item on Windows. Close is the bottom menu item on IE5 and behaves exactly as I
suggested above.

Observed with Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20010105, but
this bug has been around for a long time.
I agree entirely. This seems the best way of getting out of this whole
Close/Exit/Quit confusion. Unfortunately the `Quit' item is sacrosanct on Mac OS, 
so we'd have to retain it there, but on all other platforms we should get rid of 
this item -- because judging by the number of bugs reported about it, it's 
causing more trouble than its worth.

The only benefit a `Quit'/`Exit' item provides is allowing for escape from 
repeating popup windows, so this bug may depend on bug 29346.

See also the discussion in bug 10745, bug 13761, bug 14596, bug 17014, bug 22222, 
bug 28385, bug 29468, bug 39057, bug 39639, bug 41408, bug 43304, bug 44466, bug 
48360, bug 49261, bug 49355, bug 51584, bug 52821, bug 54331, bug 56283, bug 
57755, and bug 58865.
OS: Windows NT → All
Hardware: PC → All
I'm sorry, but windows users were trained that the system menu has a close 
item. The bottom menu of the file menu is supposed to quit the app.  If your 
training was different then you have a problem.

If you want a dialog warning about quiting mozilla that's fine, although i hope 
that bug is already filed.
> The bottom menu of the file menu is supposed to quit the app.  If your
> training was different then you have a problem.

The majority of potential Mozilla users are currently using Internet Explorer, 
where choosing the bottom item in the `File' menu does *not* close all windows -- 
it just closes the current window. When those people lose data from the `Exit' 
item in Mozilla closing more windows than they expect, you can't just tell every 
one of them `sorry, you were poorly trained, it's your problem'. That would be 
despicable.

As tpowell already said, a warning dialog on exit is bug 39057. Warning dialogs 
fall into two categories: those which result from unfortunate reality (e.g. 
cookie dialogs), and those which are symptoms of bad user interface. A warning 
dialog on exit would be an example of the latter case.

Windows users have been trained by repeated experience that the bottom item on 
the left-most menu closes the window. Whether this also happens to exit the app 
is beside the point. The observed behavior is that it closes the window--that's 
what users expect. This is partially because it is rare for windows apps to 
have more than one window. 

As Matthew (mpt) said, most users on Windows are using IE. Having a global exit 
with the same placement as IE's close button is just asking for usability 
problems. The fact that a warning dialog is almost necessary is a sign of poor 
design.
Keywords: pp
Chaning the qa contact on these bugs to me. MPT will be moving to the 
owner of this component shortly. I would like to thank him for all his hard 
work as he moves roles in mozilla.org...Yada, Yada, Yada...
QA Contact: mpt → zach
updating to new owner. sorry for the spam.
Assignee: hangas → mpt
The dependencies I've just added are seemingly unrelated, but deliberate. It's 
no good removing the user's ability to close all windows at once (i.e.
`Exit'/`Quit'), if Web authors are still able to open new windows without the 
user's consent.
Depends on: 33448, BlockJS
I disagree with this bug.

There must be a way to get rid of all of the application.

The fact that "application" here includes both brwoser and Mailnews (and IRC),
*that* is unfortunate reality, and IMO a (programming) design bug. The history
window, all browsing windows, the bookmarks window, the bookmarks search window
etc. do have something in commono, and there is a reason to close all of them at
once just as there is a reason to close MS Word (with all its documents) at
once. Sure, MS Word uses MDI, while Navigator uses top-level windows for each
"document", which is the reason for confusion. But that doesn't mean that there
are no situation, when I want to quit Navigator completely. Please fidn another
solution to not confuse users, e.g. the warning dialog. (Which isn't a good
solution, I agree, but better than removing the item altogether.)

I do need this command occasionnlly. E.g. when I browse lxr.mozilla.org and
notice that I have 30 windows open. When I'm done with my search, I don't want
to close 30 windows individually. It's faster to Exit (assuming that command
would actually work fast) and then to restart Mozilla than to close them all
manually.
There are other reasons why I might want to close Mozilla altogether:
E.g. when it consumes too much system resources.
When I want to shut down the computer. Windows is polite and asks apps to quit.
X doesn't - when I quit X, all still open apps are forced-quit, risking data loss.
It's hard, maybe even impossible, to catch all Mozilla windows. In any case
time-consuming. That's not reasonable, considering that I want to do that each
time I shut down my computer.

Suggesting WONTFIX for that reason(s).
I'd be more likely to suggest making this Windows only than wontfix. (Actually 
it already doesn't apply to Mac.) 

Although I understand the desire for a close all among some users, I think the 
masses hate it (see the duplicate bugs). Certainly Ben Bucksch showed himself 
to be an advanced users in his reasons for wanting close all and admitted that 
he only needed it occasionally. I'd hate to cause all the confusion and pain 
for occasional use among a select few users.

My goal is to make close all more difficult so that most users won't hit it by 
accident. I'd eliminate it on Windows. Removing it from the bottom menu item is 
a good step (and the point of this bug). Perhaps Shift+Close button (X) could 
close all windows? Worse case, make it a pref and disable it by default on 
Windows. Make another bug dependent on this one that has another way to close 
all. 
> My goal is to make close all more difficult so that most users won't hit it by 
> accident.

I see that reasoning and agree. But there are other, IMO better, solutions.

Netscape has long been the browser of choice for porn surfers. The one reason
for this is when the popups become unbearable and numerous, "File... Quit" will
end it *all*.

A better implementation would be on Quit notify each application and let them
popup last minute "Save, Cancel, Ok" alerts.
The endless popups should be stopped by not allowing JavaScript window.open in 
various situations (see bug 33448), therefore a global Exit should be much less 
needed. Popping up warning dialogs is a poor solution in any case, especially 
since many users are not expecting for all apps to exit.
Placing File->Close under the separator, just above File->Exit, instead of
somewhere in the forest of File menu items, would of been a much better solution.

I am a Windows user and I *love* File->Exit. I would never want it to go away.

*** Bug 80524 has been marked as a duplicate of this bug. ***
Close is placed near file items because of windows mdi specs.

I'm pretty sure we put it at the bottom on some other os (mac os?).
Mozilla is an SDI application, not an MDI one.
Microsoft itself has dismissed MDI as an outdated interface and gone totally in
favour of SDI.
Example of an application that *really* is using MDI is Opera browser.
Mozilla is nothing like that (not yet anyway).

If Close can't be put down with Exit, I think it should be put above the
separator, at the bottom of section that contains New and Open, not together
with Save As. Putting it at the bottom of the section would be a little bit more
noticeable since user would expect it to be "at the bottom".

That is the way it is done in MS Word 2000 - another example of SDI application
that has both Close and Exit in it's File menu.

If we want to follow Microsoft specs, MS Office 2000 is a quite good reference I
believe. :o)

Filed bug 80553 Move Close away from save as and near open.
Alexy, and whoever spec'd file->close to be in the middle of the file menu: we
should not be copying word processor UI for a web browser. Besides, File->Exit
in Word 2000 does what File->Close does in Navigator. Other documents opened
remain open, in their windows. I don't think it provides a way to close all
copies of Word (whether or not it's the same process is irrelivent from the
users view).

"Exit" is an extremly serious op, and if it's to remain, I'd like to see it
moved away from accidental conflict with Close under File via typo/mouseo/thinko
. The keyboard shortcut needs to go away. I can't tell you how many times my
finger sliped with 4.x and I hit alt+q instead of alt+w.

+ 4xp, dataloss, mostfreq
Keywords: 4xp, dataloss, mostfreq
nope, Exit in Word2000 closes all windows, just like it does in Mozilla.
We had more discussions about specs in bug 80553 which has spawned from this one.
Jeremy, this bug is neither 4xp nor mostfreq nor dataloss.

dataloss:
Yes, File|Exit is potentially a bit harmful (loosing some data), if hit
accidently. But
- This bug is not the only resolution to this problem.
- If you remove Exit, I'll have to force-quit Mozilla (e.g. by closing X, see
above), which won't allow Mozilla to save the profile (prefs, bookmarks etc.),
which can lead to *real* dataloss.

mostfreq:
Only 2 dups. The problem about accidental File|Exit is erported often, yes, but
again, this bug is not the only solution.

4xp:
4.x Unix does have a File|Exit, last item, directly under Close.
Keywords: 4xp, dataloss, mostfreq
Bug 39057 (display a warning dialog on Exit if multiple windows are open) is
mostfreq, 4xp, dataloss, and, unfortunately, currently marked as wontfix.
bringing a suggestion from bug 39057: why not move File->Exit to Tasks->Exit ?
when copying suggestions please copy their relevant thread. my response to that 
suggestion was 'NO'.  Tasks is about opening new modules/components.  mpt wants 
us to move the windowlist out of tasks, which will increase the strength of the 
tasks association.  If i saw a tasks menu and knew that 9/10 items opened a new 
window, i'd be really upset if i randomly clicked one item and it killed all of 
my windows.  it doesn't make sense to put quit there.

fwiw, MacOSX probably expects quit in the application menu.  On windows, the 
application menu is the file menu (this is an ancient arch flaw, but we should 
be faithful to it).
*** Bug 93567 has been marked as a duplicate of this bug. ***
The MS Office 2000 is not a good reference *at all*. It is not self-consistent.

When starting from icon (on taskbar) which is what most people do I observe the
followind behavior.
Word:
   - taskbar icon starts multiple copies (1 WINWORD.EXE process)
   - File|Exit closes them all.
   - file|new opens a new window
   - File|Exit closes them all

Excel:
   - taskbar icon starts multiple copies (>1 EXCEL.EXE processes)
   - File|Exit closes a single one.
   - file|new opens a new MDI window
   - File|Exit closes all MDI windows

Powerpoint:
   - taskbar icon starts only a single window (1 POWERPNT.EXE process)
   - New window one must be created from Window menu.
   - file|new creates a new MDI window
   - file|exit closes all MDI windows
XP has the same behavior (wow), but I also tried FrontPage:

   - file|new opens a new window
   - file|exit closes individual windows only

What a mess...

I think we should follow IE's lead and remove File|Exit (on windows and linux)

I've added 4xp because I discovered that part of what keeps confusing me with
Mozilla is that the bookmarks manager has the close button hidden in the middle
of the menu and exit as the last item. I seem to frequently exit bookmark
manager and by accident exit all mozilla applications, perhaps out of habit. In
Netscape 4.x, edit bookmarks does not have a exit menu item, just close as the
last menu item. Also of interest is that pressing Ctrl+Q when the edit bookmarks
window has focus in Netscape 4 does nothing.

How exactly is the bookmarks manager an MDI app (which is the primary reason
you'd have both close and exit menu items)? To the user, bookmarks manager
appears to be a standalone application that just handles bookmarks. Having both
a close and exit menu here is silly. It doesn't need both close and exit. Just
one that only closes the bookmarks manager.

Almost identical arguments could be made for Address Book (for whatever reason,
not 4xp, since N4 has both close and exit) and History (4xp-no exit menu item),
and JavaScript console (didn't have a menu in 4.x; only supported Close through
a button).
Keywords: 4xp
tpowell, I agree that removing File|Exit for the Bookmarks Manager, History and
the JS Console might be a good idea. I think, that this is what gives the most
gripe, right? Would that fix the bug in your opinion?

I disagree with Address Book, because it can be used as independant app (i.e.
you might start/close the Address Book without opening the browser or Mailnews).
Ben, removing File|Exit from Bookmarks Manager (the point of bugs 80524 and 
93567 duped to this one), History and the JS Console would be a step in the 
right direction, but would not completely fix this bug. As I said in the 
initial report, on the Windows platform at least, I want File|Exit removed as 
the bottom most menu item and replaced with File|Close for all Mozilla windows. 

Based on comments in this bug, I see that there are people that genuinely want 
a close-all item. For the life of me, I can't understand why some people want 
to be able to close their browser, and mail client/newsreader, and HTML editor, 
and chat program all from one menu item, but they tell me they do. To me this 
is like exiting Word and having Outlook and Excel and IE close as well. If 
that's the intent of File|Exit, I think it should be on the Tasks menu, as Exit 
All since it's most clearly related to the other applications. In fact, it's a 
better parallel there; the items on the Tasks menu open "applications" and it 
makes sense to close the applications there.

I'm probably missing the point. Perhaps the desired behavior is for browser 
exit to only close browser windows, and for mail exit to only close mail 
windows (see bug 39639). Even in that case, because Mozilla is not MDI, and 
because of IE's precedence I'd want File|Close as the bottom most menu item, 
with perhaps File|Close All as an item above it (I'm reluctant because there's 
similar accidental hit danger as with Ctrl+W/Ctrl+Q).

Sigh. Make me somewhat happier and fix bookmarks, history, and JS console.
Personally, one of the main uses of File->Exit for me is to shut down everything
before I log off the computer.  I don't care how many browser windows or other
pieces of Mozilla I may have open, I want everything to go away in one fell
swoop.  I know what is part of Mozilla, so closing mail/news is not unexpected
for me.  (Maybe I'm just an advanced user...)

I do agree that the current placement of close relative to exit is confusing. 
Why not just move close below exit?  If you have the two in seperate places,
there will always be confusion.  Besides, it would feel very strange to go to
tasks for shutting down the browser when file is where /every/ other app puts
things like that.
tpowell, it's mostly technical reasons for wanting to cloase all of Mozilla. For
example, close the Mailnews window and Mailnews still stays in RAM. You need to
close all of Mozilla for the memory to be freed.

The browser and Mailnews are technically the same app. You cannot hide that from
the user completely.

It's not a good argument to use Microsoft's current apps as precedent, since, as
alreay pointed out, they are completely inconsistent to themselves. If MS
figured out what they want and write good styleguides and make their apps foolow
it, we can discuss about that again. So far, the only style rule I know is that
File|Exit closes the application (not just the window).

Personally, I could live with Tasks|Exit All, if that is what users rightfully
expect.
Could the least contentious parts of this bug be fixed? i.e. the removal of
File->Exit from the Bookmarks manager etc. I recently took a phone call from a
distressed novice who lost all the windows they had open by attempting to close
the bookmarks menu using File->Exit. Fortunately they were able to recover those
windows through history, but it was definately perceived as a problem with Mozilla.
I think that what is suggested in comment #28 is a good idea, or at least some
kind of prompt (that can be made to permanently go away) asking whether closing
all windows is what is really intended. 
I'll find someone to fix this bug just as soon as its dependencies get fixed.
Depends on: 75371
No longer depends on: BlockJS
> There must be a way to get rid of all of the application.

There is:  
  *  Windows:  Cltr-Alt-Del->End Task
  *  Unix:     killall -9 mozilla
  *  MacOS <X: clover-Q  (sacrosanct, as someone said)

However, neither of the first two is at all kind to the
application.  Under Unix, killall mozilla without the -9
may be kinder, but there is no equivalent on Windows.

I agree, there _needs_ to be a way to do this.  However,
I also agree that it should NOT be easy to hit my mistake
when the intention is to close only the current window
or subsystem.

> The fact that "application" here includes both brwoser 
> and Mailnews (and IRC), *that* is unfortunate reality, 
> and IMO a (programming) design bug. 

I have to agree, but this (making each subcomponent a
separate process) would be a separate RFE.

> I do need this command occasionnlly. 

I think "occasionally" is the key here.  We don't want to
be hitting it by mistake when we intend to close a window,
and we don't want to be unable to do it either.

> E.g. when I browse lxr.mozilla.org and notice that 
> I have 30 windows open. 

Heh, see the Tabbed Browser preferences items in the
recent nightlies, it will help somewhat.  However, it
is still important to be _able_ to close everything.

> The endless popups should be stopped by not allowing 
> JavaScript window.open in various situations (see 
> bug 33448), 

Yes, but...

> therefore a global Exit should be much less needed. 

No, it's still necessary for other situations.  The
popup windows are just one example of a situation that
makes it necessary.  Getting the "you are low on 
resources, please close some applications" dialog is 
another.  There are others.  

> Popping up warning dialogs is a poor solution 

I fully agree here.  There has to be another way.

Proposal:

File->Close Current                       Ctrl+W
  If there is only one tab in the current window,
  close the whole window, otherwise close the 
  current tab.

File->Close...(submenu)
        ->Tab
        ->Window
        ->All [current component] Windows         Ctrl+Q
        ->All of Mozilla (browser, Mail/News, everything)

"[current component]" might be "browser" or might
be "mail/news" or what-have-you.  In commercial builds, 
"Mozilla" would be replaced with "Netscape" or whatever.

Keyboard shortcuts given above are what they should be
in Windows, other apps may vary.

Command-Q is sacrosanct on MacOS, but mail and news could
reasonably be separated from the browser for Command-Q 
purposes, especially if they are made (and they should 
be) separate processess.  
> There is:  
>   *  Windows:  Cltr-Alt-Del->End Task
>   *  Unix:     killall -9 mozilla
>   *  MacOS <X: clover-Q  (sacrosanct, as someone said)

These are the last resort, when the application went completely south, not
during normal operation (this also applies to normal |killall mozilla|).
However, I need the Exit command during normal operation.

> I have to agree, but this (making each subcomponent a
> separate process) would be a separate RFE.

I didn't suggest anything else.

> > I do need this command occasionnlly. 
> I think "occasionally" is the key here.

"Occasionally" meaning a few times a day, not once a month. There definitely
needs to be a way to do that in the Mozilla UI.

> We don't want to be hitting it by mistake

Sorry to be offensive, but then look at what you click on. I can see that you
hit ctrl-q accidently, but not File|Exit, when File|Close is far away from it.

This is (on Windows) more a matter of unlearning MSIE's broken and inconsistent
behaviour than anything else.

> File->Close Current
> File->Close...(submenu)

That would work for me, but is inconsistent with every other app I know. mpt?

(Removing FIle|Exit without replacement is *no* option, *at least* not on Unix.)
I'm actually amazed that some people would use a menu to close a single window
instead of using a mouse or a keyboard shortcut. And even more amazing is that
someone would consider changing what all our users are used to for that
*marginal * userbase of *another* browser!

I love Exit, and I love where it's placed.

Every Netscape user knows what File==>Exit does. It's the same as in Netscape 4.x.

Why should we abandon what our userbase is used to over the years, and start
immitating some other browser on some particular platform for some users that
chose the slowest out of possible 3 major ways to close a window?
Who, if they even do make mistake once or twice, most likely will learn the
lesson and avoid doing it in future anyway.

File==>Exit gives user much more power and advantage than IE does. Why instead
of being proud of it, should we immitate "the dominant browser"?

This is what some users of other browsers expect, therefore we should cripple
features of our browser to make them happy? Never mind what our own users
expect? Never mind that we do this better? Never mind that there are plenty of
users who never even use Windows and don't even wanna know about IE?

Just like several people above, I propose WONTFIX here, and reopen bug 39057.
Broadening the SUMMARY to be open for alternative solutions.
Summary: Remove File|Exit and replace with File|Close → File|Exit considered probelmatic (by some people)
A logical change would be this (but it seems gui design doesn't follow logic):

File->Exit should be moved to the Tasks menu.

Possible next step:

Tasks menu is split to two menus: Components (or maybe Tools) and Windows.
Please don't morph the bug summary. I really don't care where File|Quit gets 
moved to (I've suggested Tasks|Exit All). As I stated quite clearly in this 
bug, I want File|Quit replaced with File|Close as the last item on the 
File|Menu. This matches user expectation, especially for those familiar with IE.

I'm not asking for a warning when selecting File|Quit with no other change to 
the menu items. Quit should be removed from the File menu (and moved 
elsewhere). Power users (Ben) will find it and real users can get on with not 
being frustrated by accidentally closing all windows.

> I'll find someone to fix this bug just as soon as its dependencies get fixed.
Thanks. MPT, can you find anyone to at least fix Bookmark manager, history, and 
JS console in the meantime?
Summary: File|Exit considered probelmatic (by some people) → Remove File|Exit and replace with File|Close
*** Bug 110583 has been marked as a duplicate of this bug. ***
After reading through all of the previous comments, I think that the best
compromise is to enable a "Confirm on Exit" option in Preferences and have it
set on install.  This will not produce the perfect product for everyone, but it
will solve the problem.  Once you get used to it you can turn it off.

I do have this nagging feeling that the File menu does not conform to Windows'
File menu, say in Windows Explorer, but then again I don't think it has multiple
windows.  See my bug 11/17/01.

My suggestion, how about when you close exit, it closes the 'related'
application. You do it in browser, it closes all browser, but leave mail,
chatzilla, and others open. You do it for mail, it closes the mail and any
opened message window. It seems like a more logical behaviour to me. 

I can also live with replacing file.exit with file.close, but file.exit is just
too dangerous for average user, Maybe put one under tasks? Consider my usage for
example, I sometime (when i have two hand on the keyboard) just press alt and up
twice expecting to close the windows, but I end up kicking myself for closing a
site I didnt manage to bookmark.
I am still having periodic "thoughto" problems with the File->Exit.  It is very
frustrating when that happens.  I don't know why it is easy to select File->Exit
from the menu running in Windows, but I think that if something isn't done about
it a lot of users will hate you for it.  Please excuse my strong language, this
is not personal.
This is not a defect, and unless the spec is changed, it should be closed as
invalid.  Note that the WIG says (p 124) "If your application supports an Exit
command, place this command at the bottom of the File menu preceeded by a menu
separator.  When the user chooses the Exit command, close any open windows and
files, and stop any further processing."
Peter Trudelle, WIG was written with MDI in mind. As has been noted numerous 
times in this bug, it makes no sense in SDI or completely unrelated 
applications such as IRC chat, email, and browser. Also note that IE ignores 
the Exit menu recommendation. This is a usability bug and should not be closed 
until fixed.
------- Additional Comment #43 From Peter Trudelle 2002-01-02 12:11 -------

"This is not a defect..."

I would hope that my comments, which may be constructed better, would contribute
in some whay to the disposition of this bug.  I am detecting a little "attitude"
in several different comments.

I'm not familiar with the body of planning, "big view", etc. of Mozilla.  In
light of that, I read "application" in the WIG quote as main menu, application
just opened.  Mozilla does many other things which might be considered
sub-processes of the main process, and which as in most programs, in *most*
cases need to go back to the calling procedure or some other procedure.  When I
say "most", I mean more often than not.  In this context or model, it makes
great sense to feature an "exit program" prominently in the topmost procedure
and available but harder to get to in sub-processes, including windows and tabs,
in my opinion.

How this gets implemented is more complicated.  Perhaps Mozilla could add a
confirmation dialog for 'Exit' in all sub-processes but not on the topmost
level.  Of course, I think on the topmost level, Ctrl-W works just as well.  I
just have this nagging feeling that there is something counter-intuitive about
the way Mozilla is handling 'close' and 'exit', or at least counter-Windows, and
that's why I'm having so much trouble with it.  I think IE provides an
accelerator key for "close all windows", and then you explicitly exit.  Sorry
for rambling.
Tim:  I don't understand why you think WIG was written with MDI in mind.  It
clearly distinguishes MDI from several alternatives, doesn't limit the Exit
command to any one, and in fact does not recommend MDI, it merely notes that
"For some tasks, the taskbar may not be sufficient... . You can use MDI for this
kind of situation" (P220).  You call the components 'apps', but they are not
really separate, and in fact are somewhat integrated.  The fact that IE has no
exit command is not really pertinent, since it is a stand-alone browser that is
integrated into the OS as a file system browser. If it had an exit, you could
reasonably expect to shutdown Windows. Note that OE *does* have an Exit command.
 The current behavior here is not a defect because it implements the spec.
Severity: normal → enhancement
The question is how 'integrated' do you consider the browser componenet with 
mail and other components. It certainly looks like a sepreate app to me, except 
for the fact it uses the same framework. Thats why we have a shortcut to browser 
AND mail. Usability guide are the norm that user expect, and most user have come 
to expect file->exit closes that window. We have to think in term of user's 
perspective, that single window IS the program, and multiple window is multiple 
program (For MS Windows). For us programmers and advance users know its not the 
case, since all window instance share the same library, but usability is not 
design pattern, but it is usage pattern.

I have come to expect that File->Exit closes everythting, ever since I started
using Netscape browser (long before IE even appeared) on every platform. And I
wouldn't have it any other way. It's not a case of technicalities about
instances. It's a case of what users have come to expect from this browser, and
if you change it, there will be many unhappy people out there.
IE users once they move onto Mozilla/Netscape after a few mistakes will get used
to it. However removing this, means removing a irreplaceable functionality that
people actually are using.
Reasons for removing this are VERY objectionable. I'm quite sure there are more
people out there that use Netscape's File->Exit than IE's File->Close. Because
File->Exit actually does something, while clicking the little cross button does
the same thing as whole File->Close routine much faster and easier.

While skimming the discussion from the top *again*, I had a little idea which I
will toss out in my naivete.  I don't know how married we are to the current
"File" menu layout, but what if we changed the text of "Exit" to "Exit All" and
changed the text of "Close" to "Close Current" and put it right above "Exit" and
below the separator?  That would be pretty unambiguous, wouldn't it, and the two
items would be right next to each other in full view.
It is File->Exit, and has always been so, and for applications that have it, it
closes *all* windows and stops all processing, as the WIG says.  I don't give
much weight to arguments that this will confuse IE users, because it is a
different command from File>Close. The idea that they will be confused because
they are both the last item in the File menu is quite a stretch.  If that were
the case, then they would also expect to get a Find dialog when choosing
Edit>Preferences.  In fact, I'm not aware that we have received any complaints
about this from typical users of any version of Netscape.
Ok, Peter, I'm beginning to realize that there is only so far you can move.  You
have a mandate with the WIG and the Netscape browser.  New users of Netscape
products will get used to the Exit function or get used to unexpected program exits.

It doesn't seem to me that the back-and-forth discussion of this bug is
producing any changes to Mozilla, and maybe anything I say has already been
said.  I *would* like to say(one more time?), to offer a possible explanation of
my understanding of this bug, that in my experience on Windows 9x, the OS window
menu standard has exit window at the bottom of the File item.  I think the
Windows interface is made up of windows.

In cases where in Windows 9x there is more than 1 window (displayed or hidden),
File-->Exit closes *only* the *active* window, and I think people are used to
that.  There is no "close", even if "exit" is renamed. I think most Windows 9x
applications support the window menu standard.  I guess Netscape doesn't, which
makes it a non-standard Windows app.  That is fine - there are others (hopefully
not Microsoft apps), but in Windows, the UI and API *are* the standard - IMHO,
there is no other.
Um, there is a close.  It's just near the top of the file menu (4 items down)
instead of at the bottom.  I think this was even mentioned in an earlier
comment.  (And done on purpose, even if I don't remember the reason offhand.)
Steven: I am perfectly willing to make changes that demonstrably benefit large
numbers of users, but the burden of proof is on those who would change the
existing behavior, which is according to the design specification, and backed up
by years of usage by tens of millions of people.  It also follows the platform
standard (WIG), so I don't understand your point about NS being non-standard in
that regard. The fact that there are other apps that use only Close does not
make Exit non-standard.  I have already pointed out that OE has Exit; so do
Word, Excel, Opera, Photoshop, AOL, Acrobat, ACDSee, and other *very popular*
applications.  If lots of people are having a problem with Exit, it should be
possible to document it.
I got an e-mail on bug 65121 (this bug) with the following contents:


http://bugzilla.mozilla.org/show_bug.cgi?id=65121

This bug depends on bug 33448, which changed state.
Bug 33448 Summary: disable 'new window' when close box clicked (no window.open
in onUnload)

           What    |Old Value                   |New Value
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED

I didn't see this here or in bug 33448 so I thought it would be a good idea to
put it here.

I think 33448 is a matter for the coding of "Close" but other than that I don't
see how this bug depends on it. (please forgive my ignorance ;)  In any case,
the "state change" on 33448 is to FIXED.  If we are deciding to leave Exit and
Close the way they are, that's one thing, but I don't think that decision has
anything to do with killing or disallowing server-side popups.
I suggest Close be put back to the bottom of the File menu.

Right now it's too close to Save As -> "dataloss"
*** Bug 123225 has been marked as a duplicate of this bug. ***
>The current behavior here is not a defect because it implements the spec.

Then the spec is wrong. No surprises there, then.

> If lots of people are having a problem with Exit, it should be possible to
> document it.

It has been documented in bug 10745, bug 13761, bug 14596, bug 17014, bug 
22222, bug 28385, bug 29468, bug 39639, bug 41408, bug 43304, bug 44466, bug 
48360, bug 49355, bug 49621, bug 51584, bug 52821, bug 54331, bug 56283, bug 
57755, bug 58865, bug 71152, bug 80553, bug 86192, bug 100086, bug 108154, bug 
110589, bug 117094, bug 134100, bug 135068, bug 136583, and bug 138022.

Some of those bugs are requesting a confirmation alert for the Exit item -- 
like the well-meaning but UI-ignorant people who file bugs of the form `Make 
deleting all my e-mail at once optional', those people are filing bugs of the 
form `Show a confirmation alert before deleting all my e-mail at once'. But 
computer programs should not have a menu item for deleting all your e-mail at 
once, they should not have a menu item for closing all windows which have a 
title which starts with `P', and they should not have a menu item for closing 
all windows which happen are hosted by mozilla.exe. Such a function made 
marginal sense in the mid-1980s, when the Macintosh could run only one program 
at a time and you needed to quit out of it before doing anything else. Now, 
it's just plain cruel.

Since the dependencies have been implemented, there is no reason for this 
dataloss bug to remain unfixed. --> XP Apps: GUI.
Severity: enhancement → normal
Keywords: 4xp → dataloss
Hardware: All → PC
Whiteboard: [p-ie/win]
Reassigning.
Assignee: mpt → blaker
Component: User Interface Design → XP Apps: GUI Features
QA Contact: zach → paw
I have gotten used to the close/exit problem for the most part.  I just have to
go real slow when I'm closing a window.  BTW, does Navigator have a tabbed
window interface?

I think exceeding the spec by putting a switch for exit confirmation in prefs
would be a fair solution.
An unusual thing which has probably already been noted - ie 5.01 exits when
File->Close is clicked.  This sort of contradicts the argument that ie users
expect  'exit' to close only the current window, I think.  However, in real
situations, I had plenty of problems with the close/exit thing.
> But computer programs should not have a menu item for deleting all your e-mail
> at once, they should not have a menu item for closing all windows which have a 
> title which starts with `P', and they should not have a menu item for closing 
> all windows which happen are hosted by mozilla.exe.

I strongly disagree.
This is simply a matter of convenience. Yes I want to be able to delete all my
menu at once, without sitting and swearing for 15 minutes as I delete it one by
one. Yes I want to be able to close all Mozilla windows at a snap of my fingers.
This is simply about making things easy and convenient.

You seem to treat Mozilla as a set of different applications and tools. It's
not. It's one multi-purpose tool. If my hammer performs 2 functions: hammering
the nails in, and pulling them out, I want to be able to just throw this tool
(the hammer) away, instead of having to pull it apart and throwing 2 parts away
one by one.

We seem to have 3 conflicting factors here:

1. Different UI specs.
2. What people have been trained with other applications.
3. Common sense.

All the bugs I see that are being filed, usually come from common sense here.
"Move Close next to Exit to better contrast the functions of them to the user"
seems very reasonable to me. However I see you slam it down saying "That would
be against the specs!" Yet here, when faced with another side of virtually the
same problem, you proclaim "The spec is wrong!" in favour of what users of other
products have been trained to.

Really, why not stop looking at the specs, and other products, and have a look
at  the product we have in front of us and think what would be best for it? Stop
relying on the thinking of someone 15 years ago who had never considered or even
immagined the kind of application we have here. Stop relying on thinking of
someone from the company next door who is once again not related to our product.

People that do want to learn to use Mozilla won't be concentrating on small
things like that, and will get used to it in time just like Steven did. Most
close windows with mouse and not through menu.

This is basically an issue between people that do need the functionality of
Exit, and people who don't know about it. And we need to find a compromise here
and be reasonable about it. Leaving exit functionality easily accessible by
users and at the same time making new users aware of it. I think the most
reasonable solution is moving the menus down:

-
Close Tab
Close Window
Exit

Even if it breaks some ageless spec.
Saying "The spec is wrong!" instead, in order to delete a feature that users
heavily depend on is a bad alternative in my opinion.

> ie 5.01 exits when File->Close is clicked.

No it doesn't, it closes the current window. Some of IE gets unloaded if the
current window is also the only open window, but that (like exiting in general)
is an implementation detail which is irrelevant to humans.

Alexey, please don't claim that I said or thought something which I didn't; it's
very impolite. And if you `want to be able to delete all my menu', please file
that as a joke separately.
> exiting in general) is an implementation detail which is irrelevant to humans.

That's not true, and I already lengthly explained why. Users should be able to
say "Go away!" to Mozilla, and have Mozilla really do it. So, if you remove it
from the File menu, add it to the Tools or Window menu or whereever, but I'd
find that very strange.
Mozilla should go away completely (exit(0)) when the last window is closed. 

Prople who don't want that should use QuickLaunch. It has the 
icon on the taskbar where the exit option is.

If the startup time was improved, QuickLaunch could go away entirely.

A bigger problem for me right now (on windows) is that every morning mozilla
takes roughly a minute or even more to become completely alive again. This is
way more than the startup time overhead.

Having never touched a Mac, I am commenting for windows/linux only.
Matthew: the bugs you cite are mostly concerned with the position of the menu
item, or the accelerator used, whether the item should appear in secondary
windows, or whether a warning dialog should be displayed. Some of these bugs
have nothing to do with the current exit/quit situation (one is print, another
close tab), one bug you even verified as invalid at one point. After several
years, and use by millions of users, there is almost no support for removing
Exit/Quit entirely, certainly not enough to reverse the status quo.  IMO, this
is the sort of thing that should be handled by proposing a spec change to
n.p.m.UI, and decided by PixelJockeys if necessary.

That said, I have always supported  breaking the components into separate,
cooperating applications, which should address this and many other issues that
arise from making such a huge monolithic beast.
Speaking with mpt on IRC, he still seems to insist on completely removing
File|Exit, without replacement. Even the original reporter is fine with a move,
not complete removal.

In any case, completely removing File|Exit without replacement is *no* option.
See e.g. comment 10. Many people need it frequently, e.g. every time they log
out of X11. Such a request would be WONTFIX.
I am incline to go with comment 13. That is "Placing File->Close under the
separator, just above File->Exit, instead of somewhere in the forest of File
menu items, would of been a much better solution." A user will at least see the
option to close the window more clearly. 

We should have something like (horror) Internet explorer where navigating the
menus shows the description on the statusbar. (note it's statusbar have two
modes, one for browsing, one more like tooltip) But they all part of other bugs
(I think). So I suggestion close this as wontfix or make it depend on 115903.
Some more technical discussion and an illustration from a high-level POV:

> See e.g. comment 10.

I meant comment 8.

And re dataloss: *Fixing* this bug would cause dataloss. In many cases, Mozilla
saves its data only on shutdown. That's similar to the Save function in other
apps. So, force-quitting Mozilla (see comment 8 about X11) without properly
shutting it down will cause dataloss. "Fixing" that dataloss might take a huge
effort and it is not clear how that would work: do we save prefs.js each time
any pref has been changed? only at certain intervals? what, if the quit happens
between a change and the next save? what about all the other profile data? what
about unsaved documents in the Composer / Mailnews Composer / HTML forms
(there'll be no chance to open a "do you want to save?" dialog)?

Oh, and this is not a bug, it is an enhancement request. It follows what most UI
design *guidelines* say and many users expect. You may disagree with them, but
you cannot argue that such an implementation is a bug.



mpt says that Exit is an implementation detail. I think that applications are
*important* functional and technical (and maybe even legal) entites. I don't
think that the request that said application should now leave my computer's
operating environment is unreasonable or hard to grasp for users.

Maybe a comparison helps illustrate what I'm trying to say.

The gas tank in your car may also be an "implementation detail". Why should I
care, if I have enough gas? Why can't it "just work"? Well, it's reality that it
doesn't "just work", and it won't "just work" in the nearer future. (No jokes
about females. ;-P )

Like gas, RAM and CPU cycles are important "details" in the computer - they are
a limited resource and have to be managed. That's today done by humans; they
close applications (note: applications - closing just a few windows won't help),
when memory or CPU gets low. Maybe your mother won't, she'll just complain about
the slow computer, but many slightly more computer-literate people will.

Or maybe another comparison fits more: Should PC peripherals have power buttons?
You can argue that monitors and scanners are just an implemenation details (iMac
integrates the monitor, after all) and that a user shouldn't have to care, if
they are on or off. The monitor just has to be black. Or, at most, the user
switches off the computer and all peripherals should go off automatically.
This argumentation has some merit, and some people might agree. In fact, none of
my PC peripherals - monitor, scanner, printer, HIDs - have power switches, just
suspend modes. In some cases, I prefer suspend, in others I don't. Some people
hate suspend.
Fact is that these devices do consume considerable power while in suspend mode.
It might be unfortunate (mpt would probably say "fix it"), but it is *the
reality*. Some people agree and trade power consumption for convience, others
don't and get very pissed that they have no power button.
So, the solution is to add a power button and a suspend mode. Both groups get
what they want. The only disadvantage is that the suspend people have to pay a
few extra cents for that power button they don't need. IMO, that's a very small
price to pay (from the vendor POV) to make the other large group of people happy.

Same applies here IMO. An Exit menu item (whereever it may be) is a small price
to pay for the group of people who do care about applications and memory
consumption.
I would definitely endorse comment #67, 'I am incline to go with comment 13.
That is "Placing File->Close under the
separator, just above File->Exit, instead of somewhere in the forest of File
menu items, would of been a much better solution."'

While this would increase the possibility of errors, as a logical group it makes
a lot of sense.

BTW, I have had the most problems with this in windows *other than* the main
browser window.
I thought it was important to respond to this one.
qa --> sairuh@netscape.com
QA Contact: paw → sairuh
(Comment 26 and comment 28) Please, can we at least remove Exit and replace it 
with Close in bookmarks, history, the various consoles, dom viewer, etc. that 
are clearly supporting (not primary) windows to the task of browsing? It makes 
no sense for these to have an Exit item that can shut down everything.

Ben Bucksch, closing all windows should give the same result in terms of system 
resources as exiting the program--when the last window is removed, the program 
is shut down. This is how Mozilla currently works. Perhaps you realize that, 
but comment 68 makes me think that you don't. Ending the program by closing all 
its windows or by using Exit are just two ways to do the same thing, so I don't 
see how this is any more dataloss than the current behavior.

Removing Exit in bookmarks, history, ... but keeping it in navigator
makes no sense.

I certainly hope that the BUG in (unix-only?) 4.x version where the bookmarks
window is closed automatically after the the only other remaining browser window
will not be repeated.
> Ben Bucksch, closing all windows should give the same result in terms of system 
> resources as exiting the program--when the last window is removed, the program 
> is shut down. This is how Mozilla currently works. Perhaps you realize that, 
> but comment 68 makes me think that you don't.

I am aware of that. Everything else but be a bug, because it would leave me with
an (almost) inaccessible instance of Mozilla.

There are cases, however, where this doesn't work, e.g. when hidden windows are
open etc.. I have seen these cases (although a longer time ago, admitedly).

> Ending the program by closing all 
> its windows or by using Exit are just two ways to do the same thing, so I don't 
> see how this is any more dataloss than the current behavior.

The problem is when you have 40 windows open and closing them all manually would
take up to a minute. That is not reasonable, and a common situtation when Unix
users want to log out of X11.
>The problem is when you have 40 windows open and closing them all manually would
>take up to a minute. That is not reasonable, and a common situtation when Unix
>users want to log out of X11.

To log out, you click <some menu>->Log Out->OK, you need not manually close
mozilla, where's the problem?


> To log out [of X11], you click <some menu>->Log Out->OK, you need not manually
close
> mozilla, where's the problem?

The problem is that that (at least on most system) doesn't close the windows the
same way clicking the "close window" button on each window does. Instead, as
said above, it force-quits (or aborts or however that is called) all
still-running applications, and Mozilla won't save its data (e.g. bookmarks,
prefs etc.) and certainly has no chance to ask, if you want to save non-saved
documents or forms. -> dataloss
This is unlike Windows, which politely asks all applications to shut down, do
their cleanup and savings, and only after all apps agreed, it will shut down.
BenB: you want us to leave a dataloss bug in Mozilla in order to work around a
dataloss bug in X that affects all X apps?  That doesn't seem like the right
thing to do, especially since there are mutliple ways to work around the X bug
and no way to work around the Mozilla bug.
There seems to be an EASY solution to all of this dataloss fear.

Add the following confirmation prompt to File-Exit any time there is more than
one Mozilla window open:

Multiple Windows are open!  Please choose:

1. Close just this window/tab  (like IE)
2. Exit All running Mozilla Windows  (like NS4)
3. Cancel

This would solve this problem altogether.

Please do NOT take away File-Exit.  Just modify its behavior.  Positioning the
Close option somewhere else (lower) wouldn't bother me in the clightest.  I
never use the arrow keys to choose - just the underscored letters out of habit.

I absolutely DO agree that File-Exit with NO confirmation is a really BAD thing.

Heck, if they really had lots of time on their hands (ha!) they could add other
confirmation options:

1. Close Web Browser Windows only
2. Close Mail/News Windows only

etc.  Anyway, that's just my two... seems to me it would solve this entire mess.
See also bug 28385.

Comment 77:
> Add the following confirmation prompt to File-Exit any time there is more than
> one Mozilla window open:
> Multiple Windows are open!  Please choose:

FYI, I just attached a patch to bug 52821 ('too easy to hit ctrl-q instead of
ctrl-w') which will do that (well, not exactly that, but close).
Would it be difficult to implement it so that 

File -->[Shift]-Exit 

Closes all windows, while 

File -->Exit

Closes just the current one?

Precedents, at least in windows, include 

Start-->Shutdown-->(select 'restart')-->[Shift]-OK unloads and loads the kernel
without performing a warm reboot

[Shift]-(click close button (X in the top-right)) close this explorer window,
and all of its parents

(I'm using the word 'exit' because that's what's there, but it would really be
file-->close = close, file-->[shift]-close = exit)
*** Bug 158891 has been marked as a duplicate of this bug. ***
Lewis, yes, that's impossible to implement at this time due to bug 126189
An additional case for a warning message is that selecting
logout/shutdown/restart on windows will cause all running apps to file|exit. At
this time, applications with unsaved data get the opportunity to cancel the
restart. 

Notepad will prompt the user if he has pressed a single key in the notepad window.

Instead of asking the user, Mozilla rolls over and dies.

This can happen unexpectedly if certain programs are run ('To finish the
installation of **** shareware product 2000, my visual-basic written installer
will now restart your machine without asking first').
Dataloss confirmation for unfinished downloads (bug 28385) and for unsubmitted
forms (bug 143266) should happen also for window close, it is not really
directly related to this bug.
I still don't understand the massive reluctance to add a confirmation dialog for
the full Quit/Exit operation.  It's a very heavyweight operation, with potential
for massive dataloss, and only infrequently selected on purpose.  Since
selecting it by accident can have drastic consequences, a confirmation dialog is
entirely appropriate.

The only real argument I've heard for not having a dialog is the general
principle that too many dialogs are a Bad Thing, and that users get accustomed
to dismissing the dialogs without reading them.  I agree with this principle in
the general case, but every general rule has its exceptions, and blind adherence
to a rule of thumb is a recipe for bad design.  Remember: "A foolish consistency
is the hobgoblin of small minds."

Quit should have a dialog except for the simple case where there's only one
window (and no extra tabs), in which case Quit is equivalent to Close, and
should behave the same (exit without a dialog).  Similarly, "Close Window"
should ALSO have a confirmation dialog if there's more than one tab in the
window. since the user might not really mean to blow away all the tabs.  Both of
these confirmation dialogs can have checkboxes to allow the user to say "don't
ask me this again", but by default, confirmation dialogs should always be used
if there's more windows/tabs to close than just the current one.

The real irony here is that so many people resist a synchronous dialog that can
prevent dataloss, yet we have a VERY annoying dialog popup whenever a site
cannot be reached.  Worse yet, that dialog is asynchronous, popping up randomly
when some random window/tab has a problem, and if there's a general problem
(like an unplugged network cable), the cascading errors cause a large number of
annoying dialog boxes that need to be dismissed one at a time.  (Is there an
existing Bugzilla bug about this, or do I need to create one?)

The connection error dialogs SHOULD be avoided, in keeping with the general rule
of thumb.  However, a confirmation dialog before blowing away other windows or
tabs is desperately needed, and it's a specific need that outweighs the value of
the general rule.
> I still don't understand the massive reluctance to add a confirmation dialog
> for the full Quit/Exit operation.  It's a very heavyweight operation, with
> potential for massive dataloss, and only infrequently selected on purpose.

Quit/Exit shouldn't even *exist*, except on Mac OS. That's what this bug is about.

> Similarly, "Close Window"
> should ALSO have a confirmation dialog if there's more than one tab in the
> window.

That is bug 108973. Not related to this bug.

> The real irony here is that so many people resist a synchronous dialog that
> can prevent dataloss, yet we have a VERY annoying dialog popup whenever a
> site cannot be reached.

That is bug 28586. Not related to this bug.
> Quit/Exit shouldn't even *exist*, except on Mac OS.
> That's what this bug is about.

No, this bug is only about removing Quit from the File menu. If it was about
removing Quit entirely, I would have WONTFIXed it long ago.
Jonas, thanks for the references to the related bugs -- saves me from creating
new duplicates!  Sorry for the post; someone else in another bug asked for all
comments regarding Quit be placed under this bug, though it does seem off-topic
in retrospect.  I recopied it under bug 39057, where it's more appropriate, but
should have referenced the copy here.  Mea culpa. :-(
>> Quit/Exit shouldn't even *exist*, except on Mac OS.
>> That's what this bug is about.
>
> No, this bug is only about removing Quit from the File menu.

...the difference being? If it's not in the File menu, how are you going to
access it? I don't see it anywhere else.
*** Bug 166220 has been marked as a duplicate of this bug. ***
bug 126189 is fixed now, so how about this:

file --> close - Close window
shift-(file --> close) - Exit mozilla

(initially suggested in comment 80)
Coincidentally, bug 52821 ("Too easy to hit Ctrl+Q"), after more than two years
of discussion, now hopefully nears its resolution by replacing Accel+Q with
Accel+Shift+Q as a shortcut for File|Quit/Exit. In this light, Lewis's
suggestion to activate Quit on Shift-clicking Close seems to make very much
sense. (And keep the Accel+Shift+Q shortcut for it, as there are comments in bug
52821 strongly opposed to removing the shortcut.)

The only problem I see with this is that this way, the command would not be
easily discoverable for those few people who would like to use it. Idea: can we
have tooltips for menu items???
... no (or not yet): bug 122095; and not even statusbar tips so far: bug 47434.
If Lewis's solution is approved (and I vote for it), this bug should perhaps be
marked dependent on one of the above mentioned bugs.
*** Bug 186544 has been marked as a duplicate of this bug. ***
By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.
Severity: normal → critical
Make File->Exit close current window (as per windows standards!) on Win32, and
add a Window->Close All menu item. Everyone's happy on Win32 (no features lost,
no more lost data).

This particular 'bug' is one of the main reasons I refuse to make mozilla my
everyday browser.
A clarification about #96, as I wasn't clear enough - I am annoyed that
File->Exit in any child windows or dialogs opened by mozilla (for example, the
venkman debugger) nukes the ENTIRE Mozilla process without a single warning! Is
it possible to at least have a warning message displayed to alert the user that
all windows will be closed?
*** Bug 203916 has been marked as a duplicate of this bug. ***
It is, in fact, easy to unintentionally close multiple windows with the file
menu's current configuration.  IMO Exit is right where it should be, but Close's
location makes no sense.

As suggested by others, I support moving Close down the menu so that it sits
right above Exit, and I support having a warning message for the Exit command
when multiple windows are open (optional but set as default).

This way there is a clear difference between the two commands, and a safeguard
against misfires.
*** Bug 229321 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8

I was just bitten by this bug for the first time today. I am glad to see that it
has already undergone thorough discussion.

My contribution is this: As a long-time Windows user and Firefox user since 0.5,
it was an absolute surprise and shock to me that Firefox shut down many windows
containing many tabs when I clicked File->Exit. Whether or not intended behavior
can be considered a "dataloss bug", this behavior *does* cause loss of data (it
did for me), it *is* frustrating, and it *is* surprising. I think the numerous
dupes filed against this behavior prove that it frustrates and surprises many,
many users.

I agree with OP. File->Exit (or File->Close, whatever we call the bottom option
on the File menu) should only close the current window. I don't care what
happens to app-wide, no-confirmation forced shutdown -- whether it is moved
somewhere else in the menu system or relegated to a keyboard shortcut -- but it
should NOT be the behavior for File->Exit.
> Make File->Exit close current window (as per windows standards!) on Win32

Wrong. File->Exit means, and has always meant, to stop the (whole) application
from executing. That includes means *all* its windows. Any other behaviour would
be wrong and I'd file a bug on it.

You are thinking of e.g. MSIE's "File->Close". That "close" refers to the
window. "File->Exit" refers to the *application*.

As for data loss, see above.
I've said it before and I'll say it again: File>Exit has no place in mozilla as
a win32 application.  It works fine and makes sense in the macintosh paradigm,
but in win32, the application is tied to the window in the user's view, even if
that really isn't the case.  Hence, win32 users expect a particular application
window to close only if they explicitly close that window, not if they "exit" a
window which is tied in the backend to their other windows, but apparently has
no connection to the window that just closed for some reason when they exited
another one. 

Yes, Microsoft has this equivalent in Excel, and it is a NOTORIOUS cause of
confusion and dataloss in my office.
As a long time Mozilla user, I never find File|Exit a useful feature.  I hit it
only a handful of times.  Each time it happened, I was shocked and upset to see
all browser windows are closed.
BTW, I'm a multi-tasker by nature, e.g. I do twenty "Open Link in New Window"
before start reading each page so I do not have to spend a second waiting for
the pages to be load.  Also I use visual stimulation to control by body to
achieve my goal, that means, whether I use x button or use File menu to close a
browser window depends on which one is closer to the last place my eye's focused
on.  By the same token, whether I'll hit Close or Exit is somewhat random,
depends on which one I saw first.  In one word, I do not think about the UI, my
mind is preoccupied by the task I'm working on.

Finally, my philosophy is that when in doubt, always err at the safe side.
*** Bug 243026 has been marked as a duplicate of this bug. ***
This bug is a clear usability problem; there is no relation between different 
windows of mozilla and the quit button groups them together for no apparent 
reason. 
I suggest to rename the quit button to a 'close all windows' button, as that is 
what it actually does.
Product: Core → Mozilla Application Suite
(How is this bug different from
"Bug 39057 : Confirmation alert ("dialog") when choosing File > Quit | Exit"
?)

Brainstorming:

It seems that most of the people who hate File|Exit are Windows users, and most
of the people who love File|Exit are X11 users. Is there any way to make them
both happy, using different platform-specific menus ?

Would it help to simply re-label the menu item that closes all windows and
exits? Rather than "Exit", perhaps "Exit All" or "Exit Mozilla" or even "Close
everything and Exit"?
Correction:

Most of the people who hate File|Exit are IE users, and most of the people who
love File|Exit are Netscape users.

There's nothing wrong with File|Exit as a menu entry - even Word 2003 has it.
The only problem is with this action having an accelerator shortcut. Take that
away and you're done.

Needless to say, the Mac version should keep it. There is no reason to remove
this dataloss-inducing shortcut if Mac users like it so much, but the rest of us
can do just fine with a menu entry. It can actually be useful when you want to
quickly quit or restart a build with heavy memory leaks.

Prog.
Don't let the dream die.

Netscape once had the dream to be a platform that takes over the desktop.  How 
can a desktop replacement shut down entirely without warning?  It seems the 
FireFox developers are satisfied with it being a geek's fancy tool.  How sad!

Come on, give up your pround and do what is right.  Otherwise, when IE 7 come 
out, firefox will eat dust.
Assignee: bross2 → guifeatures
QA Contact: bugzilla
Still I see necessity in changing something related to this bug - or "bug". At least have the user choose what he wants to have, when hitting the last entry of the File menu.
Normally I minimize downloads and so I overlook them, when closing SeaMonkey with File|Exit [what I normally try to avoid by now after losing the one or another large DL ;o)].
Most [native] Windows apps have 1 window for 1 process. Each "child window" of a process should sure be closed with the closure of the process [if it doesn't block the closure]. But windows of another process of the same app [if opened] should stay where they are.
Sure, SeaMonkey closes the process with File|Exit/Ctrl+Q and all of its windows [may it be browser, a DL window and mail/news] - but at least it doesn't look like that it's only one process and so the behaviour is odd [under Windows] although it is technically correct.

I think it would be good if the user is asked what he wants to do [close current window only or the whole SeaMonkey process], when first clicking File|Exit [or however the last entry of the File menu would be entitled]. The choice should be stored into prefs.js and be changeable via prefs dialog. Ctrl+[Shift+]W would sure get obsolet in that case, what should also be addressed in a however mannered fix [SM2.0?].
Filter "spam" on "guifeatures-nobody-20080610".
Assignee: guifeatures → nobody
QA Contact: guifeatures
Component: XP Apps: GUI Features → UI Design
Assignee: nobody → jag
QA Contact: guifeatures
trunk, with its prompts like "This browser window has 3 tabs open. Do you want to close it and all its tabs?" effectively prevents dataloss for browser windows.

I suggest this is no longer severity critical.
Assignee: jag → nobody
QA Contact: ui-design
No, this prompt is irrelevant. Closing a window and exiting the browser are two completely different things. For me, former happens often and intentionally during normal browsing, but exiting the browser not. The latter is needed in entirely different situations.
the prompt is most certainly relevant to this probably not being dataloss and critical. that was the extent of my comment - and not especially relevant to the desire/need for File|Close, one which I have no opinion
Frankly, who uses a menu item to close a single window?

There is Ctrl+W or Alt+F4 for that, and most users will probably just hit the [x] on the title bar of the window to close it. One may argue if the Ctrl+Q keyboard shortcut is too easy to hit accidentally (and Thunderbird 3.0 removed it, but for Windows only), but the most common use case for File > Exit is to simply make sure that the program is entirely closed. Despite pop-up blocking, sites frequently manage to open windows here and there while browsing, so that option catches them all at once without having to visit the task manager.

Thus, my vote for retaining File > Exit in the menu. As for the dataloss argument, there is now session restore available, which may or may not retain content entered into forms or e-mails composed (the latter should have a copy in Drafts unless autosave is disabled).
(In reply to comment #108)
> Would it help to simply re-label the menu item that closes all windows and
> exits? Rather than "Exit", perhaps "Exit All" or "Exit Mozilla" or even "Close
> everything and Exit"?

Agreed, this should resolve any ambiguity what this menu item actually does.
In theory, I would be inclined to resolve tyhis bug WONTFIX. However I'm impressed by the number of users (only on Windows, it seems) who repeat time and again that on every single Windows application, the bottom item of the File menu closes only the current window and not the rest of what the same instance of the same app may have opened.

My memory of Windows may have faded in the years since I switched to Linux, but ISTR that the bottom item of the File menu used to close everything that belonged to the current application. Maybe it has changed since I left.

Leaving the functionality unchanged (there _is_ a Close Window item higher up in the same menu) and changing just the menuitem label to say "Exit SeaMonkey" (on Windows) or "Quit SeaMonkey" (on Linux or Mac) ought to gives Windows users the pause, and it ought to be easy to implement to boot (probably a one-liner GFB, or not much more). There would be no infringement of the Rule of Least Surprise since by keeping the verb we would make it immediately obvious to users who already (and correctly) expect this menuitem to close the app, that nothing has changed.

The "Are you Sure?" prompt mentioned in several comments is handled nowadays (and, IMHO, satisfactorily) by the browser.tabs.warnOnClose and browser.warnOnQuit preferences.

Neil, what do you think?
Hardware: x86 → All
Whiteboard: [p-ie/win] → [p-ie/win] [2012 Fall Equinox]
On a side note, browser.warnOnQuit is "true" by default but doesn't seem to have any effect on either way of closing (from the menu or using Ctrl+Q).

Clarifying the label that the application as such is quit/exited sounds like a good idea to resolve any ambiguity with that menu item.
See Firefox bug 502908 "browser.warnOnQuit = true doesn't warn on quit" which depends on bug 550559 (the reason apparently being that the warning is disabled when session restore is enabled, which it is by default).
Tabbed browsing has muddied the waters somewhat, and we now have File/Close Tab, File/Close Window and File/Exit. I notice that IE has File/Close Tab and File/Exit but I don't know whether that actually exits or just closes the window.

(In reply to rsx11m from comment #120)
> On a side note, browser.warnOnQuit is "true" by default but doesn't seem to
> have any effect on either way of closing (from the menu or using Ctrl+Q).
Either you only have one tab open or you have session restore enabled.
Hmm, so I've set all browser.sessionhistory.* and browser.sessionstore.* to zero or false and kept at least two tabs with a history open, but despite not having touched the browser.warnOnQuit default I still don't see a warning on File > Exit (SeaMonkey 2.14a2 nightly on Windows 7).

Anyway, with bug 550559 decoupling these preferences in the backend, that part should be fixed once that lands (and has been ported to SeaMonkey as necessary).
I have browser.warnOnQuit and browser.tabs.warnOnClose both true (also browser.tabs.warnOnCloseOther and browser.warnOnRestart) but I also have "Edit → Preferences → Display on [Browser startup|v] → (*) Blank page" because ForecastFox doesn't work in the first window at startup, and before that I used "Home Page" (actually a multitab "homepage") because I wasn't satisfied with te built-in session store subsystem. Maybe that's why the "are you sure?" popups work for me. When a session is being saved there is less need for such a popup because there is (supposedly) no risk of dataloss: your session wil come back up at next startup.

Nowadays I use "Bookmark this Group of Tabs" as a session-store mechanism: it is more versatile, since it allows any number of sessions to be saved (and kept until explicitly deleted). The downside of that versatility is that rubbish accumulates until explicitly deleted. This might be a case of ux-control >< ux-efficiency.
You need to log in before you can comment on or make changes to this bug.