Closed Bug 39057 Opened 24 years ago Closed 22 years ago

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

Categories

(SeaMonkey :: General, defect, P3)

Product:
SeaMonkey
Component:
General
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX

People

(Reporter: rekle, Assigned: mpt)

References

Details

(Keywords: dataloss)

Attachments

(1 file)

Possible Exitwindows and Setup
24.48 KB, image/jpeg
Details 
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: 24 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: 24 years ago → 24 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: nsbeta1 → nsbeta1-
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 ago → 23 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: 23 years ago → 23 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: 23 years ago → 22 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...
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: