Open Bug 65121 Opened 21 years ago Updated 5 months ago
Remove File|Exit and replace with File|Close
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.
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.
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.
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
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.
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)
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.
> 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.
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.
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 --> email@example.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.
(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.
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
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.