Closed Bug 39057 Opened 25 years ago Closed 22 years ago

Confirmation alert ("dialog") when choosing File > Quit | Exit

Categories

(SeaMonkey :: General, defect, P3)

defect

Tracking

(Not tracked)

VERIFIED WONTFIX

People

(Reporter: rekle, Assigned: mpt)

References

Details

(Keywords: dataloss)

Attachments

(1 file)

It should only exit the "Manage Bookmarks" program. It should not shut down Mozilla.
marking INVALID. The quit option is doing what it's intended to do - terminate the entire application. If you wish to close just that menu, choose 'Quit' I do intend on filing a bug soon (or you may, if you wish) to remove the Quit item entirely from the File menu and put Close in its place at the bottom but everything that you reported is working as intended.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
Then perhaps "Quit" is an inadequate name for the menu item. It should probably say "Quit Mozilla" instead to state better that it kills Mozilla entirely. Also, it seems to me that the "Manage Bookmarks" appears to be a separate app from Mozilla. It should probably not have the functionality to quit Mozilla entirely and instead just have the "Close" menu instead. Ideally, I think the "Quit" menu on Manage Bookmarks should quit the Manage Bookmarks program and not Mozilla.
Richard, you raise a good point there... in fact, Quit appears in the File menu for the History window, as well as Mail and (in commercial) Instant Messenger. i'll resummarize this bug as, "Quit in application window should say 'Quit Mozilla[or Netscape]." will reassign to UI for further input.
Status: RESOLVED → REOPENED
Component: XPApps → User Interface: Design Feedback
QA Contact: sairuh
Resolution: INVALID → ---
oops, almost forgot about the summary!
Assignee: don → bdonohoe
Status: REOPENED → NEW
QA Contact: mpt
Summary: Quitting the "Manage Bookmarks" program exits Mozilla also. → File > Quit in Bookmarks/History/etc windows needs to specify quitting entire app
Nah, this is silly. I predict that within five years `Quit' as a menu item will be obsolete (we'll need to get Mozilla startup time down to less than two seconds first though, Blake!) ... But while the menu item still exists, it should be `Quit', the whole `Quit', and nothing but `Quit'. Surely it can't be just Mac users who realize that Quit means quit the entire application?
Just realized a mistake in my 5/12 comment. I said: 'If you wish to close just that menu, choose 'Quit'' I meant: If you wish to close just that window (the manage bookmarks window), choose 'Close'
The point here isn't that only 'intelligent' people understand that Quit means quit the entire application and all it's separate windows. If you look at this from a Windows app point of view (granted Mozilla isn't only Windows, but the same concept applies to all GUIs), it appears that each separate Mozilla window, each separate Manage Bookmarks window, etc. all appear to be SEPARATE applications. They are in separate windows, separate titles, separate menu bars, etc. (To me at least, if I see a menu bar, that to me indicates a separate program.) It strikes me as VERY counter-intuitive to select the "Quit" menu item on one program and see potentionally a dozen other windows exit. If I didn't know what was going on here I'd get very upset. "Why'd that stupid Manage Bookmark program shut down Mozilla? I'd better report that as a bug..." The way I see it, every separate Mozilla window, whether it be a Mozilla window, or a Manage Bookmarks window or whatever, should act as a separate Windows app, independant of the others. Quitting one should not quit the others. The point of my bug report on this is not a request to change the functionality of Mozilla, so much as to make it more visually and intuitively clear as to what it does! I still think "Quit" should just shut down the current window and not ALL windows. Is it really that difficult to change the functionality of the "Quit" menu to just shut down the current window rather than ALL Mozilla windows? We could easily add a "Quit ALL" menu item or something similar that would kill all the Mozilla windows.
I agree. Though, I don't think the option to close windows should be "Quit" -- it should be Close, and the Quit option should be removed entirely (from the subwindows, at least-i.e. history, bookmarks, etc)....
*** Bug 39639 has been marked as a duplicate of this bug. ***
That each Mozilla/Netscape window looks like a separate application is an unfortunate design failure of Windows. As far as resolving Windows' shortcomings goes, there are a few options. First, Quit is an *almost* universal term that means "kill application," but it's not the Windows standard. Would adding platform specific terms make this more clear? In this case, "Quit" would be replaced by "Exit." Second, the "Close" command has moved from the bottom of the menu in 4.x to the top of the menu. This follows a trend in other apps where close is migrating toward the Open and Save commands. Though it would go against that trend, we could entertain the idea of moving it back to the bottom so that it's more obvious what the difference between Close and Quit is. Third, the other difference between 4.x and the current design is that, as this bug suggests, sub- or auxiliary windows did not have a Quit or Exit command. This clears up all confusion, especially since the Close command was at the bottom, therefore being the only choice at that location. This has the disadvantage, however, of providing *no* way to quit the application when you're inside an auxiliary window. Obviously, there are enough open options here that this warrants more discussion. I'm moving it to M18 so we can figure out an optimal solution.
Status: NEW → ASSIGNED
Target Milestone: --- → M18
There is a similar, 3 month old bug that has fallen inactive. davidr8@home.com reported "Quit should be changed back to Close All" marking it as dup, since this one has more discussion. Now for my two cents: should this be renamed to a platform specific word? What do other native apps call this 'destroy all windows' function? I believe macOS uses Quit, and win32 and linux(gnome, since this is GTK+) use Exit.
OS: Windows NT → All
*** Bug 29468 has been marked as a duplicate of this bug. ***
*** Bug 41408 has been marked as a duplicate of this bug. ***
This bug as originally reported is pretty much a duplicate of bug 10745 (INVALID). Putting Close next to Quit is discussed pretty thoroughly in bug 22222, DUPLICATE of bug 17014 (INVALID), and is also suggested in bug 13761 and bug 14596. Given the number of duplicates, I'd say that bug 22222 is the root cause of the problem here. Because Close has moved from its previous location near Exit, Windows users are now hitting Quit when they just meant Close. So, EITHER we get rid of Quit entirely (a worthy aim, but it would be an RFE which would have more dependencies than you'd think), and put Close at the bottom of the File menu by itself; OR we reopen bug 22222 and put Close next to Quit in the File menu to make it clear that Close and Quit do different things.
Keywords: verifyme
Interesting twist there, Matthew: the root of the problem is the position of Close; therefore, the answer is *obviously* your stated preference in several of the duplicate bugs. Sorry, I don't buy that logic. The problem is this: some users, in trying to close a window, shoot straight past the Close command and choose Quit instead, ignoring the implications of the term and assuming that the location takes priority over the command name. To please that subset of users, it has been proposed that we move the Close command to the bottom, thereby allowing some users to distinguish between command names. The problem inherent in such a solution is that there is another subset of users who have no problem finding Close near the top of the menu and would be disconcerted to find it at the bottom. We can also surmise that there would be yet another group who would accidentally hit Quit when they were aiming for Close. Clearly, there is *no* solution to this problem that will satisfy all users. The Macintosh Human Interface Guidelines have suggested the following grouping since their publication in 1992 (and this hasn't changed since the 1984 introduction of this organization, either): {New, Open} {Close, Save, Save As, Revert} {Page Setup, Print} {Quit}. This grouping is based on a logical and conceptual organization of document commands that are related to one another as well as to the object they operate on. New and Open are creation/activation commands; Close et al are the function opposite of New and Open, but they are not destructive. They are about preserving and putting away. Quit is a very different command which shuts down the entire application. Incidentally, the confusion caused (and copied in other OSes) by putting Quit at the bottom of the file menu has been *resolved* in Mac OS X, where the application gets its own menu, separate from the File menu. The Windows Interface Guidelines (1995), in contrast, do not reference the organizational structure of document commands and only mention Close in the context of Exit (i.e. if the app isn't really exiting, then use Close instead, meaning to close the visible representation of the application). Thus, Close in that case *IS* the conceptual equivalent of exit and *not* the Close we're talking about. In addition, a large number of the most popular Windows applications (e.g. Office 2000) put [Document] Close below the Open command, as Seamonkey has done. It's important to note that Windows has a long history of such discrepancies (such as Microsoft's statement that the future was MDI just before their about face and subsequent internal development of SDI applications such as IE) so a single example of Windows behavior almost never defines a convention. Unix/Linux is hard to look to for examples. Precious few interface guidelines have been laid out and the ever-changing nature of just about everything Linux leads to very few regular conventions to go by. However, one trend has rung true throughout most Linux implementations and Windows: the original logical organization of the Mac File menu into document specific commands followed by application commands has been maintained. The point of all this is that conceptually and logically, Close in this context belongs with the other document/window commands. It is a document command that operates exclusively on the current window. Quit/Exit is an application command. Placing [Document] Close at the bottom of the File menu might satisfy a few people with ingrained habits, but it simply doesn't make sense from a logical standpoint. If we make design decisions based on the habits of a few, we're going to wind up with a product that's confusing to many. Therefore, I'm going to close this bug as INVALID. If anyone wants to raise any of the other points I made in a previous post (platform-specific Quit/Exit, removing Quit from certain windows), post them in separate bugs so we can debate their relative merits separate from the position of the Close command.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago24 years ago
Resolution: --- → INVALID
That's a wonderful post, with two minor problems. * the Macintosh interface guidelines were written prior to the boom in popularity of the Web, where windows are more persistent than documents are -- so `close' is now much more a window management function than it is the opposite to `Open'. * in general, Windows interface conventions appear first in IE, then in Office, and then in Windows itself. IE has `Close', not `Quit' or `Exit', and it is at the bottom of the File menu. I'll verify this as invalid, because I think adding verbiage to `Quit' would make things worse, not better. However, I would probably support any of these bugs if they were filed (any of which would fix the problem described here): * `Mozilla components should be separate apps' * `"Quit" should be "Exit" on Windows' (pp) * `Quit menu item is obsolete' (dependent on another RFE, `Startup time should be <2 seconds').
Status: RESOLVED → VERIFIED
Keywords: verifyme
Hardware: PC → All
*** Bug 43304 has been marked as a duplicate of this bug. ***
*** Bug 44466 has been marked as a duplicate of this bug. ***
For an overview of some discussion about why it's called "quit" and not "exit" see bug 4908
*** Bug 48360 has been marked as a duplicate of this bug. ***
*** Bug 49355 has been marked as a duplicate of this bug. ***
*** Bug 49355 has been marked as a duplicate of this bug. ***
*** Bug 49261 has been marked as a duplicate of this bug. ***
*** Bug 51584 has been marked as a duplicate of this bug. ***
*** Bug 10745 has been marked as a duplicate of this bug. ***
We really need a dialog that warns users before they use the quit option. It's too easy to inadvertently close all Mozilla windows by: - Not knowing that the "quit" option in manage bookmarks closes everything. - Accidentally selecting "quit" instead of "close" in a file menu. - Accidentally hitting ctrl-q instead of ctrl-w (see bug 52821). This causes the loss of URLs, partially filled out forms, etc. Either this bug or bug 51584 should reopened with dataloss, mostfreq, and rtm keywords. (I'm not just reopening bug 51584 because everything has been getting marked as a dup of this bug.)
This bug's summary used to be "File > Quit in Bookmarks/History/etc windows needs to specify quitting entire app", but I'm changing it to "File > Quit needs a warning dialog" because many of the bugs marked as duplicates don't involve bookmarks/history. See my last comment for some other ways users have reported accidentally activate the Quit command. For quick summary, some other possible solutions that various people (including me) have proposed: - moving "Close" down near quit on the longer file menus (bug 17014) - removing "Quit" from menus of manage bookmarks, history, etc. (this bug) - renaming menu item to "Quit Mozilla" or "Close All" (comments here, bug 29468) - disabling Ctrl-W so users wouldn't accidentally hit Ctrl-Q (bug 52821) Based on the wide range of changes that various users think would be necessary to prevent accidentally closing everything, I think a dialog would be the best solution because it would cover all of these cases without getting in the way too much. Reopening with rtm, mostfreq, dataloss keywords. For future versions, it would be nice to also - not warn when there's only one window open. - have a "don't warn me again" option.
Status: VERIFIED → REOPENED
Keywords: dataloss, mostfreq, rtm
Resolution: INVALID → ---
Summary: File > Quit in Bookmarks/History/etc windows needs to specify quitting entire app → File > Quit needs a warning dialog (was: File > Quit in Bookmarks/History/etc windows needs to specify quitting entire app)
rtm-, we can't accept this type of change right now because it's too late to add new dialogs.
Whiteboard: [rtm-]
*** Bug 57755 has been marked as a duplicate of this bug. ***
*** Bug 56283 has been marked as a duplicate of this bug. ***
*** Bug 56283 has been marked as a duplicate of this bug. ***
*** Bug 56283 has been marked as a duplicate of this bug. ***
Doh. i don't know how that happened (three "marked duplicate" notes). this is 4xp. I agree that dialog is the best option. See my comments in bug 57755.
*** Bug 58865 has been marked as a duplicate of this bug. ***
*** Bug 58865 has been marked as a duplicate of this bug. ***
Moses Lei pointed out that this is 4xp, but there is no 4xp in the keywords list. Bugzilla doesn't allow me to add it, so could somebody else please do that? Thanks.
Adding 4xp. NS 4.x warns on Ctrl-Q if I have more than one window open.
Keywords: 4xp
*** Bug 56283 has been marked as a duplicate of this bug. ***
Keywords: nsbeta1
reassigning to default component owner since bdonohoe is no longer @netscape.com
Status: REOPENED → NEW
ok, this time i'm really going to do it
Assignee: bdonohoe → hangas
I constantly create new windows with the middle mouse button and close then with C-w. Unfortunately, C-q is VERY easy to type accidently when trying to type C-w, and I have lost dozens of browser windows at a shot from a typo like that. Why is there even a hotkey for a function as heavyweight as Quit anyhow? It's not something you want to use frequently, and if you only have one window open, C-w will work as well. The typo problem wouldn't be nearly as severe if the Quit function at least had a dialog box to confirm the operation...
bug owner, please change the target milestone. Suggest removing rtm. I would like to nominate for mozilla 0.8, but I can't add the keyword. Should clear the status whiteboard as well.
Blocks: 52821
No longer blocks: 52821
Keywords: mozilla0.8
Whiteboard: [rtm-]
Blocks: 52821
Unsetting target milestone - M18 is long past. Gerv
Keywords: mozilla0.9
Target Milestone: M18 → ---
How about setting it to mozilla0.8 then? Is this bug more difficult than it looks somehow?
I don't think this will make it to mozilla0.8 AFAIK the Mozilla drivers only accept critical patches to the trunk for a few days..
instead of saying what we won't do. let's attach the patch and figure out where it lands.
Triage Team marking nsbeta1-. This is a valid issue, but ns will not fix this for nsbeta1.
Keywords: nsbeta1nsbeta1-
What is so difficult about this bug? I've not had the opportunity to learn XUL yet, but from all accounts, interface changes in XUL should be trivial -- why isn't this a trivial change for someone who does know XUL? (Or if it's trivial, why can't anyone be bothered to fix it?) If this isn't going to be fixed, could we at least REMOVE the Ctrl-Q keyboard shortcut for Quit until this dialog exists?!? The Close and Quit options aren't nearby in the "File" menu, but Ctrl-W and Ctrl-Q are RIGHT NEXT TO EACH OTHER on the keyboard, which makes for a VERY expensive typo! PLEASE remove the keyboard shortcut for Quit ASAP if the dialog isn't a priority!
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
I've heard there's going to be a localization freeze (freeze on adding new text) starting this Thursday.. anyone want to attach a patch to add the dialog and try to get it r/sr/checked-in quickly? Otherwise this bug will probably have to be pushed out again :(
What should the text be for the dialog? NS4 uses "Close all windows and exit Netscape?", which is short but not quite accurate. Is "Close all Mozilla windows and exit" any better?
If this gets fixed, please put a "Show me this alert next time" checkbox there, so "power" users don't get annoyed.
Keywords: mozilla0.8
For the text, what about this: "Are you sure you want to close all Mozilla windows and exit?" I think the "Are you sure" note makes it more urgent for the reader... Otherwise "Close all Mozilla windows and exit?" is pretty clear.
"Are you sure you want to close all Mozilla windows and exit?" sounds good to me, and having a checkbox to disable the dialog is a good idea. (How would you re-enable it?) There should ALSO be a checkbox somewhere to let you disable the keyboard shortcut on Ctrl-Q. (Or a general mechanism for the user to modify any shortcut keys?) As a side note, in the special case where there is only ONE Mozilla window, there doesn't seem any need for this confirmation dialog, since Close and Quit become effectively identical in this case. But if other windows will be killed, this dialog is desperately needed...
I believe it's already possible to remove keyboard shortcuts using prefs.js, but not using the prefs panel (yet (see bug 57805)), but I'm not sure why you would need to remove the Ctrl+Q binding if it brings up a dialog. It's true that we should skip the dialog if only one window is open. That might be tricky because Mozilla does a few things by creating OS-level windows that the user doesn't need to care about counting, such as menus and tooltips. If that does turn out to be difficult to get right, I wouldn't mind seeing a shorter patch get in today to beat the localization deadline that always shows the dialog, and then another patch going in later to do the wnidow-counting check. The second patch won't be adding or changing text, so the localization freeze won't be a problem. Fwiw, I don't think a "Show me this alert next time" checkbox would be a good idea for this dialog, because even power users make typos.
A description on how to change key bindings is here: http://www.mozilla.org/unix/customizing.html#keys I totally agree with Jesse that we should first get the dialog in and then (probably in a new bug) make it so that it doesn't come up when there's only one window left. And I also agree that powerusers make typos, too. I could perfectly live without a "Show me this alert next time" checkbox and would probably never activate it, unlike many other dialogs.
*** Bug 71152 has been marked as a duplicate of this bug. ***
There seems to be nowhere mentioned here the special case when some file download or software/theme install is still in progress and the user does a "quit" (but maybe some bugs marked as dupes of this one mention it, 71152 does). I believe in this case there *must* be a dialog that explicitly states that fact, something like "2 downloads still in progress, are you sure you want to quit Mozilla and terminate all downloads?" The thing is that especially long downloads can be "forgotten" especially with iconified download progress windows. Personally I dont need an exit dialog when there are just a couple of browser/messenger windows open (maybe a preference for this?)
updating to new owner. sorry for the spam.
Assignee: hangas → mpt
Adding a special warning for when the user tries to quit while downloading files is bug 28385.
I agree with quit becoming obsolete. Hopefully it will be removed soon to prevent bad/complex user interface design...
I ran into this bug a few times, too, try to do Accel-Q, but actually doing Accel-Q. I'd like to see this bug being fixed. I didn't imagine that there would be so many dups of such a bug, though. If the user (not a script!) changed a form in any of the windows, the confirmation dialog should appear regardless of prefs. This is similar to Composers 'You have unsaved data. Save/Ignore/Cancel?', which can't be turned off either. This might be complex and be better moved into another bug. In other cases, the option to 'never show this dialog again' is a *must*. Asking for confirmation on Quit is a beginners-error. We'll look awfully stupid, if we don't have a 'don't show again' option.
Another idea: move Close to the bottom of File, and move Quit (renamed as Quit Mozilla) to Tasks. This would mimic Gnome´s file manager (where really quitting is kinda heavyweight, since it´s what manages the icons in the desktop).
I don't agree with making a distinction between being in the middle of filling out a form and just having multiple windows open. I rarely fill out long forms, and when I do, I usually stay in the same window and so I'm unlikely to accidentally hit Quit. On the other hand, I almost always have multiple browser windows open, and I consider it dataloss if all of those windows close and I can't find my way back to each of the urls quickly. If the quit-warning dialog were implemented only for the case when the user is filling out forms, it would save me from about 20% of the dataloss caused by accidentally hitting Ctrl+Q or File->Quit. I also disagree about accidentally quitting being a "beginner's error" that should therefore have a "don't warn again" checkbox. If there's a checkbox, users are likely to check the box, not realizing how easy it is to accidentally quit. That will result in this feature only protecting beginners, which is silly because at least one form of this bug (accidentally hitting Ctrl+Q while trying to hit Ctrl+W) is most likely to affect advanced users who use the keyboard and keep multiple windows open. If there's a warning for losing form data, it should be shown if the user closes the window in any way (Ctrl+W, Ctrl+Q, hitting the window's "X", etc).
I think the Netscape 4.x implementation of this bug is best: a dialog prompt asking you if you really want to quit if you have more than one window open, regardless of what it is, and can never be turned off. Of course, it wouldn't hurt to have this dialog open 100% of the time, no matter how many windows there is. We need something, no matter what.
Jesse, > If the quit-warning > dialog were implemented only for the case when the user is filling out forms That's not what I said or intended to say. > I also disagree about accidentally quitting being a "beginner's error" I meant, it is a common error of beginning *programmers* to outfit their apps with "do you really want to quit?" confirmations. There are people who always know what they do. They will be very annoyed by this confirmation. That's why I think that the option to turn it off is a pre-requirement for this feature being included. > If there's a checkbox, > users are likely to check the box, not realizing how easy it is to > accidentally quit. Maybe, we should ask for confirmation, if the confirmation dialog should really be turned off? ;-P > If there's a warning for losing form data, it should be shown if the user > closes the window in any way (Ctrl+W, Ctrl+Q, hitting the window's "X", etc). Agreed. This further suggests that this feature (confirm closing forms with data) should be moved into another bug. Anyone wanna file it? > I think the Netscape 4.x implementation of this bug is best: a dialog prompt > asking you if you really want to quit if you have more than one window open 4.x Unix doesn't do that. > regardless of what it is, and can never be turned off. Throwing too many confirmation dialogs leads to them being completely ignored. We need them to warn users about real security risks. Confirmation on app close is a *the* classical example of a confirmation dialog that must be avoided. Again (so I'm not misunderstood again), I think, this bug being fixed would be an improvement. But only if the user can turn it off easily.
Ah that's right. I never noticed it but now I remember that my Linux box never asks if I'm sure I want to close with 4.x. In fact, Netscape 4.x for mac doesn't even do that =] So, maybe have the box pop up at all times by default but make it a checkbox option in Edit>Preferences under Advanced?
This code placed at a suitable position in globalOverlay.js will request global confirmation. I've even written it so that it will require a number of open windows before asking for confirmation. But what I would prefer is to request global confirmation only if no other windows open confirmation dialogs. N.B. Not localised! var windowManager = Components.classes['@mozilla.org/rdf/datasource;1?name=window-mediator'].getService(); var windowManagerInterface = windowManager.QueryInterface( Components.interfaces.nsIWindowMediator); var quitWindows = 2; try { var prefService = Components.classes["@mozilla.org/preferences;1"].getService(); var prefServiceInterface = prefService. QueryInterface(Components.interfaces.nsIPref); quitWindows = prefServiceInterface.getIntPref("general.quit_confirmation_windows"); } catch (e) { } if (quitWindows > 0) { var enumerator = windowManagerInterface.getEnumerator( null ); while (enumerator.hasMoreElements() && --quitWindows > 0) enumerator.getNext (); if (quitWindows == 0) { var result = {value:1}; var commonDialogsService = Components.classes["@mozilla.org/appshell/commo nDialogs;1"].getService(); var commonDialogsInterface = commonDialogsService.QueryInterface(Components.inte rfaces.nsICommonDialogs); commonDialogsInterface.UniversalDialog( window, null, "Mozilla Exit Confirmation", "Close all windows and quit Mozilla?", null, "OK", "Cancel", null, null, null, null, {value:0}, {value:0}, "chrome://global/skin/question-icon.gif", {value:"false"}, 2, 0, 0, result ); if (result.value != 0) return false; } }
Neil: nice one mate :-) Any ideas on how we can avoid showing it if some other window pops a confirmation dialog up? mpt: Are we agreed that this is a desireable thing? Gerv
Gervase Markham wrote: > Any ideas on how we can avoid showing it if some other > window pops a confirmation dialog up? Unfortunately I don't understand how those dialogs are triggered :-( I would love to know because I would like to see all the confirmation dialogs triggered before any of the windows are destroyed. IIRC common dialogs have changed and my code won't work with latest builds.
I apologize for not getting to this bug sooner. For the third and (hopefully) final time, this bug is invalid. Yes, I know it has a lot of dups. And I know that in Mozilla's current state, there are dataloss problems which an alert could prevent. But an alert is not the right way to fix those problems. Here's why. Alerts are the user interface equivalent of telemarketing calls. It may sound incredible to those who haven't spent a lot of time watching people use computers, but human beings in general are chronically unwilling to pay attention to what alerts have to say. Often they will blindly cancel out of an alert without reading it at all -- especially on Windows, where many alerts are unfortunately given a close box so the user doesn't even have to read the text of the *buttons* (let alone the text of the alert itself). Because they interrupt the user's task, computer users try to banish alerts just as ferociously as experienced Web users try to get rid of popup windows. The more alerts you produce, the less attention users pay to any of them (in your software or in anyone else's), and this causes problems when the computer really *does* need to inform the user of something important. For this reason, alerts should be used as seldom as possible. They should be a method of last resort. Unfortunately, novice UI designers often regard alerts as a method of *first* resort for solving UI problems, especially since they are quite easy to implement. A: `Our users are doing {x} a lot when they don't actually want to.' (In this case, quitting Mozilla.) B: `Hmmmm ... Oh, I know, let's put up an alert asking if they're sure they want to do it.' A: `Uh, but wouldn't that be annoying if you really *did* want to do it?' B: `I suppose so ... I know, let's have a checkbox so people can turn off the alert if they don't need it!' A: `Oh, ok then ... Let's do the alert thing, with a checkbox. And of course we'll need a checkbox in prefs to turn the alert back on again.' MPT: `Oh no, not more prefs! ... <whine> <whine> <whine>' You can see an example of this process in bug 49378. Now, confirmation alerts in particular (which is what we're discussing here) should only be used when the user is at risk of considerable loss -- loss of data, loss of privacy, loss of security, loss of face, whatever. If you try to close an unsaved document in Composer, you're in danger of data loss -- so Composer asks you if you want to save the document. For the same reason, if you close an unsent message, Messenger asks if you want to save it as a draft. For each of those cases, a confirmation alert can and should be used -- but only because there is no better way of solving the problem. But having a general alert, `Are you sure you want to exit Mozilla?', would be (and is, in 4.x for Windows, unless you've dulled yourself to the pain) incredibly annoying. To make things worse, it would work only for a short time -- until you started to instinctively hit the `Enter' key whenever the alert appeared. And this habit would likely spread to other alerts, in Mozilla and elsewhere, even alerts which you actually really should have cancelled out of. That would have the potential to cause just as much dataloss as the alert was intended to prevent in the first place. Here too we have the `checkbox fallacy' -- the idea that a checkbox in the alert, to prevent it from appearing in the future, will solve the problem of some people not wanting the alert. But the problem we are trying to solve is not that only *some* people need the alert *all* of the time; rather, it is that *all* people need the alert only *some* of the time. Even the most experienced user will occasionally press Control+Q instead of Control+W by mistake. For that reason, a checkbox to turn the alert on/off *all* of the time is useless -- just as a similar checkbox was in the `Add Bookmark' dialog, for example (bug 68654). So, if there are problems which result in loss from unexpected exiting of Mozilla, they should be filed as bugs/RFEs for ways of solving the individual problems, rather than plastering the general case with an alert and making the user experience worse every single time they exit. * If accidentally exiting Mozilla, then starting it up again, takes too long, then the dependencies of bug 7251 should be fixed. * As Jesse said on 2000-09-28, people often close browser windows accidentally while entering a form (e.g. a message in a Webmail service). But having an alert on Mozilla exit wouldn't fix that problem, since it's a problem with closing any given window (rather than with closing the whole app). For that, bug 48333 should be fixed. * Since exiting the app from one window closes seemingly unrelated windows, bug 65121 should be fixed (as it has been in Internet Explorer for quite some time). All of these particular problems can be solved by methods which are more pleasant (and as a result, more reliable) than asking the user every time if they're sure they want to exit. Presenting the user with an alert every time would be overkill; it would imply arrogance on the part of the Mozilla application; it would imply stupidity on the part of the user; and it would make every other alert which the user sees (in Mozilla and elsewhere) less effective. For those reasons, I will not allow it.
Status: NEW → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → INVALID
mpt: sure :-) Just for future reference, you probably want WONTFIX rather than INVALID. Marking what is really an RFE as INVALID seems a bit odd :-) Is the issue that the File | Quit menu item should be something more sensible like "Exit Mozilla" filed somewhere else? That's what this bug was originally about, but it morphed into a bug to implement a solution rather than one discussing the problem. Ah... I see you don't agree with that either. I think the issue is that (particularly when and if we get different skins for different apps) people don't realise all the parts are the same application so, although they have general knowledge that Quit means "Quit this application" they may not extend it to realise that quitting their mail program will kill their web editing program, particularly if they are used to starting them from separate icons. Gerv
I agree with Gerv. Bugs in Netscape 4.x or old Netscape 6 products are INAVLID. Not bugs filed by "us" or RFEs for Mozilla. Use WONTFIX, if you think that a bug is not a good idea. REOPENing. mpt, while I generally agree with your opinion about msgboxes, you failed to give good alternatives. Bug 65121 (removing Exit altogether) is no option at all on Mac and Unix and it is questionable of it is even a good idea on Unix. The other bugs you mentioned don't help me with th case where I have 30 windows open with pages that I wanted to read later and accidently hit ctrl-q instead of ctrl-w after finishing reading of one of those pages. In this case, the *URL*s are the data that I lost. The only other solution I see is something that works similar to Total Recall (the Aphrodite feature for crashs). I.e. on ctrl-q, the open URLs are saved and accessible the next time I start Mozilla. But that solution has its own problems. Also, consider time to implmentation: What do I do until the other features are implemented (which can take quite some time)? Should I suffer dataloss in the meatime, or should we use an inferiour fix (warning dialog) in the meantime? > particularly if they are used to starting them from separate icons. huh? Once you started either Navigator or Mailnews, you cannot (or at least should not) start the other via icons in the OS - multiple instances of Mozilla running on the same profile risk profile corruption. You have to start the other app from the tasks menu or equivalent in Mozilla. This is because it is techincally the same app, and it is at the same time a strong hint for the user that it is the same app.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
It wasn't worth reopening :-) Re: URL data loss: are they not in your History? > Once you started either Navigator or Mailnews, you cannot (or at least > should not) start the other via icons in the OS Alecf is working on (and had working for a bit, before it regressed) a fix to get a second attempt to start Mozilla to pass control to the running instance. So from a user point of view, they click the Mail icon, a mail app comes up. I still think this is a worry. Gerv
Status: REOPENED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → WONTFIX
> Re: URL data loss: are they not in your History? Sure, they are, but burried with tons of other URLs that I do not care about anymore.
verif. BTW, please do not reopen bugs to get the perfect resolution for it. It's fine invalid too :)
Status: RESOLVED → VERIFIED
mpt: Would you approve a warning if there are more than one window open?
I can answer that one for him with 99.9% certainty - No :-) Gerv
>Now, confirmation alerts in particular (which is what we're discussing here) >should only be used when the user is at risk of considerable loss -- loss of >data, loss of privacy, loss of security, loss of face, whatever. You *are* at considerable danger of data loss, in the form of not being able to easily find the URLs you were at again. Again, I think the distinction between having forms filled out and having many browser windows open is artificial. >it would work only for a short time -- until you started to instinctively hit >the `Enter' key whenever the alert appeared. No, you'd instinctively hit enter *while trying to quit mozilla*, which is perfectly reasonable. I don't automatically hit 'y' or 'n' when I see a "are you sure you want to save" dialog; I do alt+f4,n as a gesture to exit without saving and alt+f4,y as a gesture to save and exit. >it would imply arrogance on the part of the Mozilla application; it would >imply stupidity on the part of the user; and it would make every other alert >which the user sees (in Mozilla and elsewhere) less effective. It doesn't imply arrogance to assume that users will occasionally hit Ctrl+Q while trying to hit Ctrl+W any more than it does to assume users will occasionally try to exit a word processor without saving first. I don't think "it would make other alerts less effective" is a good reason to not use this dialog, since this dialog would be directly preventing data loss.
I will only say that I agree with mpt's post 100%
I fully agree with mpt"s arguments, but I'd like to remind of the case where quitting will actually terminate one or more (lengthy) downloads and thus *will* lead to data loss (or time loss). I think it is more frustrating for the average user to be able to quit from Mozilla and terminate open downloads, than to get a reminder in those cases. Also, I think for those who actually *like* warnings it might be a compromise to provide yet another preference option. The other way out of this would be to have downloads as seperate processes which *must* be terminated individually (this would have the advantage too, that crashes wont affect downloads ... I am sure there is a RFE for this already, but as long as I dont get the individual process I still want the warning :)
What about moving Quit under the Tasks menu, and moving Close to the end of the File menu. "Quit" makes no sense under file operations. And now, with Close in the middle of the menu, and Quit at the bottom, I'm constantly hitting it by accident, when I mean to only kill the current window.
Bah, this bug is too long, so here's my short answer: NO.
Quitting while files are still downloading is already covered in bug 28385. Go and vote for that if you want to see it.
There is clearly a problem here, which needs a solution. Users are selecting File > Quit when they mean to select File > Close (I have nearly done this at least once). The various solutions (listed in my prefered order) seem to be: 1) Removing the File -> Exit option, as with IE. 2) Renaming File -> Exit to File -> Exit Mozilla (specifically, Exit shortBrandName). File -> Close would renamed to File -> Close Window. 3) Providing a way to restore Mozilla to the state it was in before quitting, similar to hibernate mode in Windows 2000. 4) Displaying a warning box before closing Mozilla. Option 1 has good points and bad points. The Exit option allows for a quick shutdown of your computer, but means people can close down mozilla without checking that they don't want all the open windows. I don't see any disadvantages with option 2, but it doesn't tie in with platform guidelines. IMO it is close enough for the difference to be irrellivent. Option 3 is good, and a useful feature, but I don't think it is the correct solution for the bug. It would also require a lot of work. Option 4 initially sounds good, but the arguments about too many dialog boxes making users ignore the important ones is valid. I no longer like this option.
Summary: File > Quit needs a warning dialog (was: File > Quit in Bookmarks/History/etc windows needs to specify quitting entire app) → File > Quit can be chosen by users intending to use File > Close
Option 3 is not as complex as you think; this is partly Alphanumerica's Total Recall technology, which is pretty simple. I have a plan to try and get a version of it checked in soon. I like Option 2; we need to adapt to the shift the Mozilla is an application with extensive state - and the state is not obviously connected, particularly when Mail/News and Navigator have different icons. So people are likely to attempt to remove some of that state and accidentally pick an option which kills it all. Option 2 warns against this without being intrusive. Gerv
Since it shouldn't often be necessary to select this menu item, I'd suggest renaming it (option 2) and also moving it under the Tasks menu, maybe even into the Tools submenu under that. Many people may habitually hit the exit option in the File menu even if it's clearly different from the close window option, especially if it's at the end of the menu. The bigger problem is the keyboard shortcut. I would argue that there shouldn't even be a shortcut for this. Even if there is, it's just too easy to type C-q instead of C-w, since they're next to each other -- here is where a dialog before exiting is REALLY important to avoid losing state. (And even if you could restore it, you shouldn't have to.)
*** Bug 86192 has been marked as a duplicate of this bug. ***
This bug sucks and I think MPT's "social engineering" comments are going way overboard. So what if the dialog is ignored!? Having a lifeline is well worth it. If people are so stupid that they ignore all dialogs, then it is their fate to wallow in the horrid horrid pit of despair that ignoring all dialogs will land them in.
I hate to repeat myself, but since this idea was never addressed, here's an exact paste of my last comment. --- What about moving Quit under the Tasks menu, and moving Close to the end of the File menu. "Quit" makes no sense under file operations. And now, with Close in the middle of the menu, and Quit at the bottom, I'm constantly hitting it by accident, when I mean to only kill the current window.
I think this idea is good for win32, but the mac platform handles the multiple windows of moz in a different manner, one that is common across apps there, and so the quit location won't be going anywhere (on that platform, at least). This still doesn't solve the problems of ctrl-q and -w, which I now see is a different bug and so I'll direct my further comments there.
Jeremy M. Dolan, I don't like it. I'm used to the fact that the last entry in the File (or corresponding) menu of every application closes all traces of the app. I just had a situation where I needed File|Quit: I searched in Mailnews, but closed the dialog without stopping the search. I think, it continued in the background, without any chance for me to stop it. So I closed all of Mozilla via File|Quit.
Mozilla is a platform, Quit is like a reboot. > This still doesn't solve the problems of ctrl-q and -w Remove ctrl-q, problem solved. Quit is too dangerous an operation and causes too much dataloss to have such a convienient key... that's like having windows reboot if you hit 'a' and 'e' together. > I'm used to the fact that the last entry in the File (or corresponding) > menu of every application closes all traces of the app. Used to this from where? IE doesn't do it. Gnome's file manager doesn't. Other Windows apps don't (They only use 1 window). Just the contrary, people are used to the bottom entry under file Closing the current window. And that's why there's a problem. That's why this is a mostfreq bug, with quite a few votes. > without any chance for me to stop it. So I closed all of Mozilla via > File|Quit. You couldn't have gone to Tasks|Quit Mozilla, to rectify this rare situation?
Is it just me, or am I the only intellegent person here that reads FILE->EXIT. In all applications I've seen, the last menu item is always exit which does just that, EXIT. NOT CLOSE! Not only does this clearly mean that mozilla (everything about it) will shut down, but there is a hotkey for closing the mozilla windows, which is CTRL+W. Which is in my opinion a lot easier than just pressing alt+f, up, then enter! And if you are really on that alt+f junky stuff, just press c afterwards. That should close your window no problem. Theres a half a dozen ways to close a window, we don't need to re-organize it to taylor it your ways. This is not burger king, you can't have it your way.
Your request [which you repeated as Additional Comments From Jeremy M. Dolan 2001-07-24 12:52] was answered by me. ------- Additional Comments From timeless@mac.com 2001-04-23 22:49 ------- Bah, this bug is too long, so here's my short answer: NO. it was explicitly directed as a response to your suggestion.
> Mozilla is a platform No. "Mozilla is an open-source web browser" <http://www.mozilla.org/>
Once again, I think a great deal of this problem is the difference between the way Mac and win32 apps work (and I think this is making the mac people unappreciative of complaints from win32 users). Macs have a toolbar that is independent of the (in this case) mozilla browser window. For them, closing a window and quitting an app are definitely not the same thing. Furthermore, it is possible (common?) for mac apps (in my limited experience) to still be open while the windows are closed. Therefore, mac apps (again, in my limited experience) all have quit and mac users don't see a problem with it in moz. However, win32 apps all have their own toolbar and closing that window 99.999% of the time is synonymous with quiting the app. Win32 users don't have the same mentality; they see each mozilla window as its own app (indeed, each window has its own button on the taskbar) and the notion that this is just one app that should/can be exited from one window is just not there. <quote>Is it just me, or am I the only intellegent person here that reads FILE->EXIT. In all applications I've seen, the last menu item is always exit which does just that, EXIT. NOT CLOSE! </quote> Don't be insulting. Distinctions between exit, close, and quit are not clear in win32 because of the way win32 works as described above. We only have one common way of quitting an app: close the window. Quit, exit, and close are very similar in usage and meaning unless you're a mac person who know's what they do in the mac os. In the rest of the world, they're synonyms. Telling a win32 person to close or exit an app are the same thing. This is not an OS holy war, I just think that everyone needs too look at these different perspectives when they're making judgements about what's reasonable and expected on every platform. Finally, appending "Mozilla" as in "Quit Mozilla" shouldn't cause so much heartbreak and would clear the darn thing up!!!
> Quit, exit, and close are [...] synonyms. That's wrong. In the Word 6 world, Close meant close the current document window (which for me resembles a browser window), while Exit or Quit meant close the whole application, including all its document windows. I don't know about others, but I do know the difference between an application instance and a window instance. (This is not meant as insult.) > Telling a win32 person to close or exit an app are the same thing. Sure, if you "close the *app*", you exit. App is the keyword here, not close.
On Mac Classic the menubar begins like this: <Apple> File Edit ... The item "Quit" is *always* the last item in "File". Moving it would badly confuse Mac users. Please don't move it on Mac Classic. On Mac OS X the menubar begins like this: <Apple> <App name> File Edit ... The item "Quit <App name>" is the last item in <App name> (in this case item "Quit Mozilla" in menu "Mozilla"). Again, moving it would confuse Mac users. Please don't move it on Mac OS X, either. I think moving "Quit" on Windows, Gnome and KDE to a location other than the one described in the UI guidelines of those platforms would also confuse the user. I see three problems here. 1) Inexperienced users of Windows and X11 don't have a crisp idea about what closes a window and what closes an app. 2) Users of Windows IE think the last item in the File menu closes the window. 3) On a QWERTY keyboard 'Q' is next to 'W'. #1 and #2 are non-issues for me, but I'd like to have protection against problem #3.
Word 6 is going back quite a bit in time :) I don't have a copy to look at, but Word 6's multiple documents were all children of a master window that contained them, right? That's a bit different. Note also that later versions of word gave every doc its own window and got rid of that concept (although I'll give you excel 2000, which has a nasty mix: each doc has it's own window, and has exit which closes all of them *plus* clicking the close "X" in one window closes the entire app--totally unexpected behavior) Additionally, I'll give you point (2) as mentioned above, as "Exit" in word2k does the same thing as moz. Back to my point: "Sure, if you "close the *app*", you exit. App is the keyword here, not close." Fine, but win32 users don't equate quit or exit to "close mozilla." Just changing the wording to match the OSX behavior described above would clear that up. As for "1) Inexperienced users of Windows and X11 don't have a crisp idea about what closes a window and what closes an app." --it's not a matter of experience, the fact is that the concept doesn't exist on win32. Changing the wording to match OSX would help with that. "exit mozilla" clearly tells you you're about to say goodbye to all of mozilla. (3) I agree with.
> No. "Mozilla is an open-source web browser" <http://www.mozilla.org/> Bug 63976. Gerv
The following rant was originally intended for a private email, but I figured it expresses my view and some historical perspective, both of which have been beaten to death (this bug is resolved after all). but for some reason this bug isn't dead enough for some people (please learn to beat dead bugs in newsgroups instead of bugzilla, where it slows down developers who have to read the mail before they get to important stuff). [[is stuff i'm adding to the original text/message, oh whoops, message/plain -text?]] > I was surprised to learn that on Windows, > the menu says Exit, but the shortcut is Ctrl+Q. I guess ctrl-x has always (for some duration long enough to be beyond what i remember of windows 3.x and below) been taken by cut. [win3.1 Exit to Dos ..., Quit <doing action> v. Exit <location>] > I was going to ask your opinion but I found it myself. opinion: I hate that [[this]] bug. Apple finally got it right in OSX by making an Application menu. unfortunately by making it the name of the application, and given application names vary in length you lose the stability [[of menu length and position]] that macos assured people... {BAD}. If you can compress the application name to just the appicon, it might actually work (I wonder...) The File menu is unfortunately used on windows as both a document and application menu, mdi at least solved this by leaving two little buttons w/ defined behaviors. double clicking the top one would try to kill the app, and double clicking the lower one would try to kill the document. I blame Netscape for the problem we have today where applications have multiple menubars :). [[<ot reason="This is really fodder for another bug, but since we're talking about invading that Tasks menu I figure it's fair game in a bug that is already dead and should never go anywhere">]] This gets really bad in Mail, where you have File and Message, in nc4 Message[New Message] and File[New[Message],New Folder]. In moz, we ********** up even worse because there's File[New Message,New[Message],?Folder?] and Message[New Message]. [nc4] Aside from Message>New Message, the entire menu is basically context{message} sensitive. If we got rid of the really stupid New Message, and then promoted this format, we could have a Page menu that handled things like Info, Source, Save, Print, and leave the File menu for Tasks. -- Doing this of course makes no sense, because (a) it's counter to what everyone expects, and (b) the reason file is first is because it's a useful thing to have first. --**arg**. [[</ot>]] There was an approach which people took for a short time of giving all (or most) menu items icons. It didn't help the blind, but for some reason blind people are smarter than visual people (maybe they're just more careful and attentive). Exit usually got a Door closing icon, I don't remember close's icon but it was something distinguishable [from Exit]. The stupid thing w/ Close being near file is wholly netscape's fault, and is easily resolved: If people want to quickly close a window they should learn one of the following behaviors: * click [x] <- invented by microsoft to make things easy - w95 [[who knows, maybe this was because of web browsers and other stupid apps which made it hard for people to figure out how to close a window. Or perhaps it's really just a shortcut to the next option which newbies wouldn't be able to learn on their own]] * double click appproxy icon <- invented by microsoft because some people don't like keyboards [windows 3.x or older] [[the reason this exists is as a shortcut to system-menu>close, which owns alt-f4]] *systemmenu:close. click system-menu [alt-space works, so should alt;space, alt,left,space alt,left,down ...] > close [c works, up,enter would work in nearly all cases but wasn't guaranteed, downs{x5},enter would work for normal windows and down,enter would work for normal dialogs] [[this was labeled w/ the next item, as they were expected to be equivalent -- and some people liked keyboards]] * alt-f4 <- invented by microsoft because ctrl-? got too confusing and too risky [windows 3.x or older] -Ok, so that's the list of standard ways to Close a window. Now the fun stuff. Windows3.1 used program manager or an equivalent application known by system.ini as shell. (windows95 uses explorer by default]. When you try to Exit Program Manager it would ask if you wanted to Exit Windows. This was a serious question. Perhaps because it's slightly unexpected that closing one application would close all other applications, perhaps because restarting windows and all the other applications took time... Explorer has something similar, it's known [probably laughingly] as Start>Shutdown. triggering it doesn't instantly kill your computer (vmware's power off button does, so does the on off switch on your computer -- if you have one -- maybe) Instead it asks you something akin to ~where do you want to go today~. Depending on your os and configuration the options vary. [Log Off, Suspend, Restart, Restart In Dos Mode, Quit Explorer (*-this option is unlisted, ctrl-shift-alt-click the confirm button). Start>Suspend (sold separately, not available in some locations, void where prohibited...) doesn't ask any questions. but it doesn't really do anything serious. Start>Log off (I'm starting to log off but i just couldn't finish, ...) asks "Are you sure you want to log off?" and provides to answers 'Yes' and 'No' this is strange because MPT has repeatedly assured us that Microsoft doesn't believe in Yes no answers, not even to yes no questions. [[If netscape, windows, or bugzilla crash (or If I lose power) before I commit this message I will be _very_ upset, i wonder why, and I wonder which]] Start>Undock (available for your amusement if you can thoroughly confuse windows98 -- sometimes it will even give you scroll arrows just because ie4 couldn't imagine needing to grow the menu height even though it added an extra item) -- I've never successfully used this option, probably because i only got it while using a desktop. Undocking shouldn't be fatal to windows or most programs so I'd imagine you wouldn't get a prompt unless Microsoft really had briefcase well integrated (Briefcase --for those of you who forgot it or missed it -- which should be all of you since it was a major flop [*XP will revamp it, new name too iirc]-- allows you to perform file synchronization by carefully sticking things into this special 'my briefcase' which is probably a folder, but whose voodoo no one (including most people at microsoft i suspect) understood. Briefcase was probably just a toy/demo applet like MSBackup and MSAntivirus -- the likelihood of it being well integrated is very near nil) in which case microsoft could have asked a question better than NC4's [Go Online] Send unsent messages when going online? perhaps sync items w/ briefcase before undocking? --speaking of briefcase, w2k just brought up the items to synchronize dialog it's ui is nice and simple [?] [x] [there are no items to synchronize] [settings] [close] <- i clicked here. Hrm, it was a dialog, I'm pretty sure it said close, and I know mpt has been trying to convince me that windows dialogs shouldn't have close buttons. ... Oh wait. The reason this bug isn't dead yet is because I can't convince everyone to remove the File>Close menu item because ... Can I sell you guys the Brooklyn Bridge? we don't need a Close menu item. [see above] Now what do we know? [[<ot> Some window managers (ie null) don't provide widgets to do things like gracefully close windows. certainly they don't provide widgets to gracefully quit applications. these null managers don't even provide window switching, listing or anything else of interest, it's a good thing netscape4unix provided all of them.</ot>]] NC4 which i've mentioned before is this browser in a long line of browsers that broke various rules for window interfaces and stuff. Since people use it like Program Manager, it asks a question like Program Manager [well kind of, it actually matches Explorer's log off option not the Shutdown option in w2k]: [Netscape Exit Confirmation] Close all windows and exit Netscape? yes/no. <- again there's that pesky Yes No answer to a pesky yes no question. Now people have suggested we implement this dialog, I'm for it, perhaps that's because I occasionally accidentally trigger ctrl-q and then immediately press space in response to the bell because that's how i cancel the erroneous command. Yes I'd accept that dialog in mozilla, especially because mozilla is trying to be a platform rivaling windows3.1 and Navigator is the next Program Manager. Foreword: mpt thinks mozilla should be a platform in the other sense (a toolkit) [would you like JavaScript for Applications with that? 'SpiderMonkey' would you like JavaForApplications with that? 'OJI/Waterfall'], where each application runs separately, which means you could Exit navigator while leaving mail open. perhaps someday, not today, and perhaps never if all applications become http://localhost/mail/baz.xul although we could try to implement ie's browse as new process (that's 20 bugs filed and futured, no one's working on them, perhaps they're all busy bickering here). Would i object to this? no, i even filed some of the bugs. Can we do this yet? of course not, that's why the bugs exist. Back to random ranting. Communicator introduced this extra menu for _launching_ applications. Windows95 introduced this button called Start for getting people to laugh at microsoft. Start>Shutdown. Applications>Shutdown. I'm pretty sure Microsoft is in the interface hall of shame for this one. Ask mpt and he'll gladly point you to it. there are a few differences. 1. Windows doesn't instantly kill itself. 2. the bottom X items (at least three, plus one separator -- 8 here that's w/o an Undock or Suspend) don't run programs (users don't think help is a program). People are capable of scanning from the start button to "Programs>" and then the separator and whatever extra apps microsoft (originally only users stuck stuff here but ...) placed above. If Microsoft had called their button Tasks instead of Start, we'd probably be more able to consider the Tasks>Exit proposal. (maybe). fwiw, beos avoids looking silly by calling the Deskbar button 'BeOS' w/ one of the BeOS logos so it looks pretty not silly. -most of the above repeats what other people wrote, now for the reply form <mpt@2001-04-22 05:17> I apologize for not getting to this bug sooner. ? you already wrote a few times. <mpt@2001-04-22 05:17> this bug is invalid. ? provide a reason <mpt@2001-04-22 05:17> it has a lot of dups. definitely not a reason <mpt@2001-04-22 05:17> there are dataloss problems which an alert could prevent :) <mpt@2001-04-22 05:17> But an alert is not the right way to fix those problems. <mpt@2001-04-22 05:17> human beings in general are chronically unwilling to pay attention to what alerts have to say. This is why someone invented sound, someone else invented speech, and someone else invented flashing for those who can't hear. On windows I hear an audible beep whenever I get the nc4 quit dialog. Since I use nc4 w/o any reasons for sounds to appear, this gets my attention very quickly. And this is why alerts have very short messages w/ very simple answers (Yes/No, Ok/Cancel, sometimes help) <mpt@2001-04-22 05:17> Often they will blindly cancel out of an alert without reading it at all There must be something wrong with this, but I don't see it. There should never be a problem w/ the user canceling a dialog. All actions should be repeatable. ... Do you want to buy this product? cancel. [reread, what product was i buying?] [click] Do you want to buy this product? cancel. [reread, how much was i going to pay for it?] ok yes I want to buy it... Supposing I went to a car dealership (where they make deals not cars) <dealer> Do you want to buy the car for $60k? ]poor student[ what?! hold on a sec. can't i get it for less? <dealer> Well... I could get you the car for $54k ]poor student[ hrm can I think about it for a bit? <dealer> Well you know I can let you have it for $50k on the spot right now but only if you buy it in the next minute. ]poor student[ cancel. Sorry I'm broke. wanders somewhere else and eventually finds a car for $8k. Canceling perhaps 40 times in the process (student isn't very smart -- i'm not it, I don't drive) <mpt@2001-04-22 05:17> especially on Windows, where many alerts are unfortunately given a close box ? The NC4Exit Confirmation dialog is a dialog it has a close box, but that's for consistency because it's a dialog, you can't click it, it's disabled. <mpt@2001-04-22 05:17> so the user doesn't even have to read the text of the *buttons*. WRONG. <mpt@2001-04-22 05:17> computer users try to banish alerts just as ferociously as experienced Web users try to get rid of popup windows. Ok. So let's try a netscape user case. typethisthatalkaQuitsfhwejktetc*BONG* NO!hskjfshdkjfdhgkjdhglkjsd iureyt eu *BONG* NO!! ghkjfghkjrghkjdghkjfdhghjkfsdlhljfkadhf <send> File>Exit *BONG*. NO!! hrm, it didn't quit. File>Exit *BONG* NO!! ... it didn't quit, maybe i did something wrong. File>Quit. *oh* it asked me if i _wanted_ to quit, well... Yes i do. Yes. *smile* <mpt@2001-04-22 05:17> The more alerts you produce, the less attention users pay to any of them No problem. <mpt@2001-04-22 05:17> this causes problems when the computer really *does* need to inform the user of something important. Like saving my very important albeit overly long and totally useless bugzilla post? <mpt@2001-04-22 05:17> alerts should be used as seldom as possible. No problem. <mpt@2001-04-22 05:17> They should be a method of last resort. No problem. <mpt@2001-04-22 05:17> novice UI designers often regard alerts as a method of *first* resort for solving UI problems, especially since they are quite easy to implement. A: `Our users are doing {x} a lot when they don't actually want to.' (In this case, quitting Mozilla.) B: `Hmmmm ... Oh, I know, let's put up an alert asking if they're sure they want to do it.' A: `Uh, but wouldn't that be annoying if you really *did* want to do it?' B: `I suppose so ... I know, let's have a checkbox so people can turn off the alert if they don't need it!' A: `Oh, ok then ... Let's do the alert thing, with a checkbox. And of course we'll need a checkbox in prefs to turn the alert back on again.' MPT: `Oh no, not more prefs! ... <whine> <whine> <whine>' Problem: MPT is flooding bugzilla w/ comments and preventing people from adding features and improvements Response: well isn't that his right? and what if he's right? Problem: well that doesn't solve the problem, it doesn't even complicate it. Solution: no more mpt ... <whine> <whine> <whine> Mind you, I don't know if I want a pref for this. program manager had one, netscape didn't. <mpt@2001-04-22 05:17> confirmation alerts in should only be used when the user is at risk of considerable loss. <mpt@2001-04-22 05:17> If you try to close an unsaved document in Composer, you're in danger of data loss -- so Composer asks you if you want to save the document. <mpt@2001-04-22 05:17> For the same reason, if you close an unsent message, Messenger asks if you want to save it as a draft. <mpt@2001-04-22 05:17> For each of those cases, a confirmation alert can and should be used -- but only because there is no better way of solving the problem. We couldn't make the user Edit>Select All. Edit>Delete. File>Close? The macos equivalent would be to take the workspace document and drag it to the trash. This requires effort and isn't going to happen when you Cat uses your mouse or keyboard. <mpt@2001-04-22 05:17> general alert, `Are you sure you want to exit Mozilla?', would be (and is, in 4.x for Windows, unless you've dulled yourself to the pain) incredibly annoying. Apparently many people like it. <mpt@2001-04-22 05:17> To make things worse, it would work only for a short time -- until you started to instinctively hit the `Enter' key whenever the alert appeared. Interesting. I do hit enter. That's No, Don't Quit. If i want to quit I think about it and click yes [notice the distinction. I might even type Y because i've thought about it in advance]. <mpt@2001-04-22 05:17> And this habit would likely spread to other alerts, in Mozilla and elsewhere, good habit's aren't bad. inconsistent behavior might be. <mpt@2001-04-22 05:17> even alerts which you actually really should have canceled out of. Disconnect here. The default for Quit and the default for other things is cancel. You've (ok i ) ingrained the correct behavior, or at least the correct understanding. <mpt@2001-04-22 05:17> So, if there are problems which result in loss from unexpected exiting of Mozilla, they should be filed as bugs/RFEs for ways of solving the individual problems, rather than plastering the general case with an alert and making the user experience worse every single time they exit. It should be noted that quitting w/ -turbo doesn't kill the app anymore. !! There was a feature (Total Recall, mentioned here again ... repetition is bad) which persisted data from when mozilla crashed. If that feature persisted session history and form data then i'd probably stop caring about Quit. -- Heck, at that point Quit could be renamed Suspend and moved to Tasks. <mpt@2001-04-22 05:17> All of these particular problems can be solved by methods which are more pleasant Reimplementing an operating system is not more pleasant than creating a dialog. you said as much when you mentioned newbie ui developers. <mpt@2001-04-22 05:17> Presenting the user with an alert every time would be overkill; <mpt@2001-04-22 05:17> arrogance ... Mozilla yep, we offer to take over web types and handle browsing and ftp and mail and ... we're arrogant, that's why people use us. <mpt@2001-04-22 05:17> imply stupidity ... user maybe. but talk to Bill Law's wife (bug 48333) about closing her email that she was spell checking. <mpt@2001-04-22 05:17> and it would make every other alert which the user sees less effective. You said this before. Bugzilla is not a place for compositions (which is why my comment is 99% ineffective) repeating yourself w/in a comment (again why my comment is bad) is bad [* see] <mpt@2001-04-22 05:17> I will not allow it. Get off your soapbox, you don't own Browser. you don't own SeaMonkey. -- According to sources Office XP _can_ be mdi at your preference. I'm not going to install it just to take a picture of it, but I'm sure someone else could if anyone cared. OfficeXP is modern (unlike newmod, oldmod, mod3, mod6, ...). Appendix 1: Interesting live bugs at time of posting bug 7251 Startup bug 28385 Quitting while Downloading Bug 39639 Mail isn't a separate App wrt Quit. bug 48333 Webforms - nice to see mpt doesn't agree w/ real users about spell checking. bug 52821 too easy to hit ctrl-q instead of ctrl-w bug 57805 front end for remapping keyboard shortcuts (user-defined keys) bug 65121 Browse as New Process - right, start by building a complete os around mozilla (bugs filed, see before) bug 19454 Total Recall [RFE] C r a s h Recovery Hibernate. [aka Suspend] -probably use Total Recall bug ????? Crash -- I'm 99% sure we have a RFE to force mozilla to crash bug 80553 [win] Move Close away from save as and near open. bug 49378 - another example of a zombied bug. bug 33448 improve pr0n browsing by suppressing window.Open for onUnload fun quote: <bug 29346 Prevent repeating pop-up windows. Comments From Mitchell Stoltz 2001-01-08 10:47> I just composed a long reply, which then got erased when I visited another page <grumble>
*** Bug 100086 has been marked as a duplicate of this bug. ***
*** Bug 100086 has been marked as a duplicate of this bug. ***
*** Bug 108154 has been marked as a duplicate of this bug. ***
*** Bug 110589 has been marked as a duplicate of this bug. ***
*** Bug 117094 has been marked as a duplicate of this bug. ***
*** Bug 134100 has been marked as a duplicate of this bug. ***
*** Bug 135068 has been marked as a duplicate of this bug. ***
*** Bug 136583 has been marked as a duplicate of this bug. ***
*** Bug 138022 has been marked as a duplicate of this bug. ***
*** Bug 138022 has been marked as a duplicate of this bug. ***
*** Bug 140166 has been marked as a duplicate of this bug. ***
I have an interesting tack on this issue. I know people like to use the mouse, but they could use the accel keys. They could even set up their own keys to do it.
That actually gives me an idea. What about just removing the access key for Quit? There's still always alt-f, q, but there's no way to accidentally hit that like I constantly friggin do with ctrl-q. My control (and other UNIX users) is RIGHT NEXT TO Q. Very bad.
*** Bug 141681 has been marked as a duplicate of this bug. ***
As I said in Bug #65121: 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.
*** Bug 148163 has been marked as a duplicate of this bug. ***
I quote from the C-Net Mozilla 1.0 review: "For example, when we ran File > Quit from the JavaScript debugger, instead of closing just the debugger window, it closed all of our Mozilla browser windows, as well--definitely not the behavior we expected or wanted." This does confuse people, in their case Quit was quit a sensible option to choose (to close all javascript debugger windows). Can't we just rename them to 'Close Window' and 'Quit <appname>'?
*** Bug 149813 has been marked as a duplicate of this bug. ***
*** Bug 155575 has been marked as a duplicate of this bug. ***
*** Bug 157069 has been marked as a duplicate of this bug. ***
I've done my best to read through all the comments before my eyes glazed over, but i didn't see anybody defending the Ctrl-Q hotkey. Why is it still there? What are the arguments for keeping it?
Hopefully <Ctrl>Q would fall under the key-remapping like the rest of the keys. Actually, personally, I think I might be less likely to hit <Ctrl>Q by accident then trying to use the File menu to close a page.
Ctrl-Q is bug 52821. Quite frankly, it's BS that this bug is marked wontfix. If anything, make the OS windows / linux, and fix it by either removing it entirely or making the menu item more desciptive ("Quit Mozilla"). Quit is a common term on macs, not on windows.
This needs to be fixed, not dismissed.
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
it does not. it was resolved as wontfix by gerv, with blessings (of invalid) from blake and mpt, and verified by zach. mozilla.org will not accept a fix for this bug.
Status: REOPENED → RESOLVED
Closed: 24 years ago22 years ago
Resolution: --- → WONTFIX
rubber verifying to restore state for the nth time after many useless reopens, the most recent of which was not authorized by anyone who controls the userinterface for mozilla.
Status: RESOLVED → VERIFIED
Summary: File > Quit can be chosen by users intending to use File > Close → File > Quit | Exit can be chosen by users unwilling to look for File > Close
I count 30 duplicates. What do we need? 60? 100? Is the C-Net article not enough? You guys are being completely unreasonable. And if you don't like me re-opening bugs, then set bugzilla to not allow it.
The Last Word: This bug is about users choosing File | Quit and unexpected things happening. It was WONTFIXed when the solution was presented of a confirmation dialog. Other solutions to this problem may be acceptable. Please file bugs suggesting them. It has nothing to do with hotkeys such as Ctrl-Q. If you would like that removed (and I'd cheer you on), please file a bug requesting that, if there isn't one already. Please, no more spam in this bug. Gerv
Whiteboard: "Confirmation dialog" solution WONTFIXED.
> Other solutions to this problem may be acceptable. Please file bugs suggesting > them. Bug 65121, "Remove File|Exit and replace with File|Close".
One final note. There are two things which well-intentioned (but inexperienced or misguided) designers -- such as, alas, most people filing bug reports in Bugzilla -- persistently but incorrectly think are valid ways of solving usability problems. (1) Preferences (e.g. bug 146352, bug 115539 comment 79, bug 17639 comment 0). (2) Alerts (e.g. bug 74937, bug 128025, bug 103354 comment 1). Both techniques are extremely bad substitutes for fixing the real problem. Preferences to solve usability problems are bad because few people ever change them, and typically the choices they offer are equally undesirable. And alerts to solve usability problems are bad because few people ever read them, batting them away like flies so that they are simultaneously annoying *and* useless for achieving what they were supposed to achieve (e.g. asking for confirmation, or reporting an error). The most obscene proposals combine both (1) and (2), suggesting a confirmation alert *with its own* preference -- as was the case in this bug report. These proposals are almost always (not always, but almost always) wrong, because it's not true that some people need the restricting effect all the time and some people need it none of the tim. Rather, *all* people need the restricting effect *some* of the time, which is something an alert can't do, so the underlying design is faulty. In this case, the fault is that the `File' > `Quit'/`Exit' item is present in the first place, when it should not be. In recognition of (1), Bugzilla triagers (including myself) have regularly marked bugs of the form `Have a preference to make {x} not suck' as duplicates of the bug `Make {x} never suck' (e.g. bug 59131, bug 61199, bug 69276). I would be quite happy to extend this to (2), so that bug reports requesting an alert before performing {y} are marked as duplicates of the bug report to remove {y} or make {y} easily undoable. In that case, this bug would be marked as a duplicate of bug 65121.
Summary: File > Quit | Exit can be chosen by users unwilling to look for File > Close → Confirmation alert ("dialog") when choosing File > Quit | Exit
Whiteboard: "Confirmation dialog" solution WONTFIXED.
I think the presence of the `File' `Quit'/`Exit' item is not the fault. Exit is a nice feature of all software ;-) The problem is that Q is beside W on the keyboard, so if you use ^W a lot like I do, sometimes you will see all mozilla windows disappear. So the solution would be to remove the ^Q shortcut.
I understand that this bug as it stand is resolved "WONTFIX", but I thought I'd make a short comment. I personally think that the wording "Close" is to close in meaning to "Exit", perhaps making our problem worse. I think changing "Close" to "Close Page" would be helpful. However, I'm sure others have suggested this solution and for some reason that won't happen either. I think these selections in the File menu, as they stand, are not well-conceived from point 0.
I'm sorry to add to the spam, but given that I strongly disagree with the outcome of this bug, I feel I must voice my opinion. But that said, I'd rather someone direct me to a newsgroup or some such forum where I *can* voice my opinion. Again, I'm sorry if this query troubles anyone.
newsgroup netscape.public.mozilla.ui on news.mozilla.org However, module owners alone make decisions on whether a bug should be fixed or not (in some cases their managers might make a decision). but the users don't
Mpt, I appreciate your reasons for not wanting a dialog or a preference. I recently got in a heated argument over at another bug dealing with this issue (the one that wants to get rid of File>Quit). My question is: what solution do you think would work for this problem? Personally, I think modifying quit to read quit mozilla (or quit $appname) would be best, and apparently this follows OSX behavior. I don't think you can discount this bug as invalid. Quit is used a lot on macs, but not on windows (not a lot, anyway, and not to cover such disparate applications as a chat program, browser, mail window and javascript debugger). This is like if in microsoft office, if you choose exit in excel, it closed powerpoint and word as well.
Ben, that's why Quit should be remoevd on non-mac. there's a bug filed for that, evne
On windows Quit has been replaced by Exit, which is standard for windows. However, Quit Appname and Exit Appname are both valid phrases, so this is not a problem. I'd file a bug to change Quit/Exit to Quit Appname/Exit Appname, and Close to Close Window, but those changes have been mentioned before in this bug and nothing has happened. (see my comment #85 http://bugzilla.mozilla.org/show_bug.cgi?id=39057#c85 ) Are there any serious problems with this as a solution?
Sorry, hard to keep track of this bug, the summary keeps changing.
One problem with file-->(Exit mozilla) as the _only_ solution is that windows calls the 'quit application gracefully' command when the user chooses START-->shutdown/restart/log off/etc. (or a setup program tries to restart windows), in the hope that the application will give the user a chance to abort the shutdown if there's data they'd forgotten about. While notepad, word, etc. warn the user, mozilla just quits. For this reason, a confirmation dialogue is necessary, even if the command itself is deprecated and removed from the menus. (Just to spread this across all the bugs where exit warnings are discussed, because I am bad and evil and like generating spam for people)
> While notepad, word, etc. warn the user, mozilla just quits. Not true. Notepad, Word etc. are *editors*. Mozilla Composer and Mozilla Mailnews Composer *do* display a warning dialog, if appropriate. You could argue that the same should apply to forms in webpages with long texts typed by the user.
Ben, you're quite right. I was under the impression that IE warned the user on logoff, but in fact it doesn't. Sorry. I found bug 48333 for warning on exit when forms have been edited...
Attached image Possible Exitwindows and Setup (deleted) —
I don&#180;t understand this very long discussion, but i think it is not verry difficult to include this Exit-Window and include also a Chekbox in Preferences and the users can decide. Look like -> See my attach.
I've mentioned it before, but see also bug 28385, which would pop up a warning if you were downloading something and clicked on Exit. Would that be enough to keep people happy, I wonder ?
[I posted this under bug 65121, because it's still active and might get more attention there. However, it's more appropriate here despite the WONTFIX resolution on this bug, so I'm reposting it here too. I'd rather see this bug reopened than discuss this under the other bug, but I'm afraid a WONTFIX bug will simply be ignored...] 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.
Sorry for the duplicate post. It belonged here in the first place, but having already posted it under a less appropriate bug, I should have only referenced it from here. Mea culpa. :-( I'd still like to see this issue revisited. Keep in mind that *editors* aren't unique in having valuable state that could be lost -- each and every browser window or tab has a little editor in the URL bar, and with a large number of windows/tabs, that can add up to a lot of lost data...
*** Bug 165046 has been marked as a duplicate of this bug. ***
Unbelievable stubbornness! People, you are way too easy on the WONTFIX trigger. Isn't it obvious that for many Mozilla users, this is genuinely a major problem? A good solution was suggested, and adding this as an *option* would have satisfied both camps. First this and now Bug 37867 becomes another WONTFIX. I just don't get how such highly requested and needed enhancements get the axe... Prog.
I agree with comment #149. I honestly prefer the additional confirmation Netscape 4.x gave me when I selected File->Exit. And it should, because if there are many browser windows open, regardless of what's going on in them, this will affect _all_ of them. Netscape 4.x also had the File->Close option, closing only the current window. The suggestion showing the screencap from Opera is also viable. Please reconsider.
this has been the BIGGEST waste of time. It's a joke. Goodbye.
*** Bug 173752 has been marked as a duplicate of this bug. ***
Component: User Interface Design → Browser-General
On regular basis, I hit ctrl-q accidentaly instead of ctrl-w ! I vote for a dialog to confirm my exit when I have a lot of windows open with a lot of tab inside. I don't understand the mozilla point. But I understand the request for a confirmation dialog. Thanks.
*** Bug 191329 has been marked as a duplicate of this bug. ***
I think lack of this feature is a fundamental problem is the ease of use of this software. I am not sure why there is so much of reluctance in adding a "confirmation window" when one uses File->Quit? This is so fundamental. There is no File->Quit in IE!
I second comment #142. Imagine you have entered some very clever comments into the "Additional Comments" input field (or written a long message within the text input field for google groups). Maybe you want to start a new sentence like ". Quite .." and want to press S-Q, but press instead C-Q ..... This is data loss.
> Maybe you want to start a new sentence like ". Quite .." and want to press > S-Q, but press instead C-Q ..... > This is data loss. No, this is bug 52821. Which has been mentioned before here.
Bug 52821 debates the ease with which this data loss is triggered, but the lack of any confirmation is truly the reason why the data loss occurs. If a confirmation alert would pop up, bug 52821 would be inconsequential -- it would be about the minor inconvenience of canceling the alert, rather than the major dataloss which now occurs to many users on a regular basis. This data loss can be just as significant as in an editor, and discarding data during exit should be treated just as seriously. There are times when a browser window contains content (often dynamic) which cannot be retrieved again. Even when it can, the URL may not be known to the user. Also, with the proliferation of weblogs, plenty of editor-like state can be lost if an HTML form is discarded before being submitted. It's "obvious to the most casual observer" that a confirmation alert is called for before quitting the entire application, and there wouldn't be a need to remove the Accel-Q keybinding, given a confirmation. So why hasn't it been implemented? This bug's nearly 3 years old, and users continue to suffer data loss on a regular basis because of this...
(Just for the record: I just stumbled across my comment 62 and couldn't believe what I read. I am against confirmation dialogs for the browser, unless HTML forms are involved. *shutting up*)
No longer blocks: 52821
*** Bug 199680 has been marked as a duplicate of this bug. ***
*** Bug 212398 has been marked as a duplicate of this bug. ***
All like me who want's a confirmation dialog on exit (especially by accidentally clicking on the X in the right upper corner) should try "Tabbrowser Extensions": http://white.sakura.ne.jp/~piro/xul/_tabextensions.html.en If more than one Tab is open, Exit brings up a Confirmation Box. It's a nice and helpfull feature and should be integrated into Mozilla. The other features like moving Tabs, Crash Recovery, ... are also very good.
re: comment 162, Mozilla trunk apparently already does that. I have Mac OS X build 2003070908 and I get an alert sheet if I try to close a window with more than one tab open.
I disagree with the outcome of this bug, but the argument mpt (person who WONTFIXed it) makes in comment 71 is a very good one: This solution would not necessarily prevent dataloss. I just want to make sure all the dataloss problems have been cured, because I am still finding dataloss problems with Mozilla. If you just finished writing a long post here at Bugzilla, for example, and want to select all (Ctrl+A) but your finger slips and you hit Ctrl+Q, the entire post is deleted forever. Major dataloss. Also comment 64 describes a problem where you could just forget the URLs you were looking at. I'm going to look at what has and hasn't been resolved in the world of dataloss: I. Forgot the URLs you had open Status: Invalid. Workaround: Open History and look at the pages most recently visited. A hassle but a minor one. II. Quit while a download is in progress. Status: Bug 28385. How this will be fixed is unknown to me but a solution that also manages to fix the other dataloss issues would be nice. If bug 18004 was fixed and Mozilla properly supported pause/resume this would not be a dataloss issue. However I think the proper behavior would be for Mozilla to keep a download manager process open (by default) and not include that in the quit action. III. Hit Ctrl+Q or Ctrl+W by accident (a "potentially destructive key"). Status: Bug 52821 (cross-posting this because it is relevant to both bugs). If a user was comfortable with using Ctrl+Q (each time I reference Ctrl+Q assume I also mean Ctrl+W along with it) he would not want a confirmation dialog every time he used it (although I suspect the number of people who actually use Ctrl+Q are significantly fewer than than the number of people who lose data to Ctrl+Q). Looking at this from a comment 71 POV I'll assume that we need to prevent dataloss for a person who is comfortable with Ctrl+Q but is about to lose data because he hit the key accidentally (the worst-case scenario). Lesser instances of people who would never use Ctrl+Q would be solved by an optional confirmation. Having the option to remap Ctrl+Q without any confirmation would still allow at least one dataloss to occur before the user realizes Ctrl+Q is dangerous. Possible solutions to the worst-case scenario, however, are more complex. Here is one solution I propose to this dilemma: If 1. user has manually entered data into a form (disregard anything that was a default value) 2. that data was less than an accidental stray letter, search string, login/pass, or other forgettable data 3. the data is not the site's responsibility (e.g. if I type an e-mail and hit preview, and the preview is stored server-side, it could be argued it's e-mail provider's fault for not keeping the message stored in the event of a Ctrl+Q, crash, or other such catastrophe), Then 1. We could save the data in an undo file, so the user can come back soon and decide he shouldn't have closed the browser. (Privacy/storage issues, see below.) 2. We could show a mandatory confirmation in that instance; if later on someone in their regular use receives the confirmation erroneously and finds it frustrating they can file a bug so the system can be fine-tuned. 3. As a remarkably odd third option, we could pioneer a system for server-side prevention of dataloss; for example if a user quits the developer could re-route the lost data to the server and it could be automatically submitted to the server. We could also implement onBeforeUnload (bug 68215). This approach would create a lot of tedium for both Mozilla and web developers as well as the evangelism team, and I don't see it working as a solution to this problem. It would not prevent dataloss on any site that has not implemented such a safety mechanism. A few reasonable assumptions can be made: 1. If someone accidentally quits and didn't want to, he'll try to get his data back right away. So if someone quit and their data was stored in an undo file or something like that, there is no need to retain it for very long. One day or one closing/reopening/closing again of the browser is more than long enough. 2. Only the data entered and a mental cue to its origin (URL or title) is important to a person who has experenced dataloss; no need to store HTML or anything like that in an undo file. 3. The disk cache is big so few will care about or even notice an undo file that is the same amount of data that was entered. However if you have something very private typed up in an e-mail, again worst-case scenario, you would not want to accidentally lose your very private e-mail but you would be uncomfortable with having it stored in the undo file. Users who care about privacy, though, will educate themselves enough to find out about an option to flush the undo file, much the same as they will know that they need to empty their disk cache, history, etc. Therefore both storage and privacy issues are fixable with an undo file. IV: Hit the exit menu option, close button, or Alt+F4 by accident. Status: This bug, pretty much, WONTFIX. And although I do admit that only a stupid or an impaired person would make that mistake, we should consider stupid and impaired people important users as well. The best solution in that case would be the general confirmation dialog. Some of the Ctrl+Q strategies (data entry detected = confirm/undo) would work in this situation as well, but many people would rather not deal with these protections with these obvious methods even though they want them with Ctrl+Q. Perplexing situation, but if it were my call I would treat these the same way as Ctrl+Q if it didn't result in issues with space, privacy, or excessive frustration. Whatever happens, we need a fix sooner, not later. Dataloss, especially of such a common and frustrating nature as this, needs to be stopped before it does any more damage. I can always be quoted as saying, "There's no such thing as too much Undo."
Correctness: I might have been clearer had I stated that the data must be MORE than just forgettable search strings.
Skewer, if you want a fix "soon", I suggest you download Firebird. It would have certainly been easier than typing all of that. (And no, I didn't even read it. I doubt anyone else will either). The inability to fix issues like this, and many many others are why Seamonkey is going the way of the Dodo. The UI is astoundingly bad considering the competency of it's programmers. Give up. Download Firebird today. [This comment brought to you by the No-More-Seamonkey-Releases! commitee.]
*** Bug 226846 has been marked as a duplicate of this bug. ***
I am one of the stupid or impaired persons mentioned in Comment #164 and once again I hit CTRL-Q instead of CTRL-A, of course with ten unbookmarked web pages open (before ;-). I still cannot understand why there is no confirm dialog as was in Communicator. This dialog would do no harm to anybody, but be very useful.
Jürgen: FYI, there was a check-in to Firefox four days ago that should resolve this issue for FF users, so if that's you, check out bug 250983. Dropping off CC.
Operating system: Windows 2000 Program: Firefox 0.9.2 File menu has "Exit" as its final choice; Alt+f, Alt+x results in immediate exit from Mozilla, even if other Mozilla windows are open. In contrast, Internet Explorer does not have a Exit in the File menu, so this mistake can't occur. There should be a confirmation dialog box before closing every Firefox window. Note: When the active Mozilla window has multiple tabs open, and the user closes the window with Alt+F4 or the X box in the upper right corner of the window or by double-clicking the Mozilla icon in the upper left corner of the window, a confirmation dialog appears. Mozilla is so careful to protect the user when there are multiple tabs in one window, and so uncareful when there are multiple windows. This is inconsistent. Note: for most Windows programs, Alt+F4 is the same as File, Exit. For Mozilla, Alt+F4 closes only the current Mozilla window. That adds to the intution that File, Exit is "harmless" and won't close EVERY Mozilla window. Please add a confirmation dialog box on File, Exit whenever there is more than one Mozilla window open.
Product: Browser → Seamonkey
As I am not willing to switch from Mozilla to Firefox (I love Mozilla and its built-in apps), the only work-around for this bug is to immediately open a second tab in your first Mozilla window. Stupid, but it works (how can I automate this?). Someone at Mozilla seems to be thinking, data entered in one tabbed window is worth more than data in twenty normal windows.
*** Bug 278813 has been marked as a duplicate of this bug. ***
Ok, Guys, the dialog is there, because you get it if you try to close a single browser *window* with more than one open *tab*. Why can't the same dialog be used to warn the user if there is more than one *Mozilla* *window* open? Jim H. (aka CuriousJ)
This should also be flagged as an inconsistency with Netscape 4.x. Netscape 4 always warned you if you tried to exit while there was another window open.
Flags: in-testsuite+
Flags: in-litmus+
Flags: blocking-seamonkey2.0a1?
Flags: blocking-seamonkey1.1.6?
Flags: blocking-seamonkey1.1.5?
Flags: blocking-seamonkey1.0.10?
Reverting test edits. Gerv
Flags: in-testsuite+
Flags: in-litmus+
Flags: blocking-seamonkey2.0a1?
Flags: blocking-seamonkey1.1.6?
Flags: blocking-seamonkey1.1.5?
Flags: blocking-seamonkey1.0.10?
I've read through this long thread. The Mac options for Closing Window and Thunderbird's Quit are two keys next to each other (CMD+Q, CMD+W) - it's very easy to accidentally quit. I believe it would be beneficial to have a user-configurable option to confirm before quit/exit. The default can be OFF, so everyone is happy.
> I've read through this long thread. Then you've surely seen bug 52821.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: