Closed Bug 14807 Opened 21 years ago Closed 18 years ago

Win32: Browser doesn't gracefully quit at shutdown or restart

Categories

(SeaMonkey :: UI Design, defect, P2, critical)

x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.0

People

(Reporter: mcafee, Assigned: law)

References

(Blocks 1 open bug)

Details

(Keywords: dataloss, platform-parity, Whiteboard: [adt1 rtm])

Attachments

(2 files)

Forking the windows part of http://bugzilla.mozilla.org/show_bug.cgi?id=2425
to this bug:

If you shut down a Windows 95/98 or NT system, all currently applications should
gracefully shut themselves down as well. However, Raptor doesn't respond
correctly to the shutdown event, and keeps running; eventually Windows will
prompt the user to force-quit the application.
OS: Solaris → Windows NT
Hardware: Sun → PC
Mac bug is P2, marking this one P2.
Priority: P3 → P2
Whiteboard: [Beta]
QA Contact: leger → cpratt
Summary: Win32: Apprunner doesn't gracefully quit at shutdown or restart → [PP] Win32: Apprunner doesn't gracefully quit at shutdown or restart
Still a problem with the 1999102908 builds under Windows...
Priority: P2 → P3
Target Milestone: M13
targetting m13, p3.  Does this still happen, perhaps on NT only?  I haven't seen
it on Win98 in a while.
Status: NEW → ASSIGNED
Target Milestone: M13 → M14
Keywords: pp
Target Milestone: M14 → M17
Summary: [PP] Win32: Apprunner doesn't gracefully quit at shutdown or restart → Win32: Apprunner doesn't gracefully quit at shutdown or restart
Mass moving M17 bugs to M18
Target Milestone: M17 → M18
mass-moving all bugs to m21 that are not dofood+, or nsbeta2+
Target Milestone: M18 → M21
moving en masse all bugs that didn't get nsbeta3 nomination to "future" milestone
Target Milestone: M21 → Future
The problem now seems to be that we don't detect that the system is shutting
down and thus don't prompt the user to save mail messages, html pages they're
editting, etc.

We need code to handle the shutdown notifications (WM_QUERYENDSESSION and
WM_ENDSESSION) and to do the standard File|Exit processing.

Don't forget to turn turbo mode off!

I'm resetting the target milestone and adding dataloss keyword.

I think this is a Mozilla 1.0 issue because fixing it requires some architecture
to get from the low-level Gecko window procedure (where the WM_QUERYENDSESSION
goes) to the embedding application (not necessarily the embedding window).
Severity: normal → major
Keywords: dataloss
Whiteboard: [Beta]
Target Milestone: Future → ---
See also bug 101500, turbo won't shut down gracefully when logging out of NT.
Just tested this in today's build (2001092503) on Windows NT4sp6a.

* In turbo mode, bug 101500 still applies - Windows is unable to get Mozilla to
shut down, and comes up with 'Wait/End Task/Cancel' dialogue box.

* When not in turbo mode, Windows succeeds in shutting down Mozilla itself, but
the shutdown is not quite graceful - an open Composer window with unsaved text
was killed without the 'Save/Don't Save/Cancel' warning.

I think Bug 101500 isn't quite a duplicate of this.
Target Milestone: --- → mozilla1.0
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
*** Bug 111123 has been marked as a duplicate of this bug. ***
taking QA since turbo related
QA Contact: cpratt → gbush
this bug has obviously morphed over the ages. anyway, over to a XP Apps component
Component: Browser-General → XP Apps
I can't let this get pushed out past mozilla1.0 that way.  I think we really 
need to fix this one.  At least I'm going to make somebody make an explicit 
decision so I have somebody to blame when people come after me about this.

Changing target milestone to untargetted, severity to "critical", and adding 
bug 100319 as being blocked by this one.
Blocks: 100319
Severity: major → critical
Target Milestone: mozilla1.0.1 → ---
No longer blocks: 100319
Target Milestone: --- → mozilla1.0
*** Bug 122064 has been marked as a duplicate of this bug. ***
I got this bug also on Win95.
I think this bug is produced somewhen when surfing and then somehow the tabs
don't work correcly; there are some tabs not closable.... Maybe I get a
performance loss also, but this might be only in my opinion.
Maybe this bug occurs when many popups are opened.

You might have a look at my attachment connected with dup bug 122064 (output of
task manager):
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=66663
renaming, apprunner is dead & gone.
Summary: Win32: Apprunner doesn't gracefully quit at shutdown or restart → Win32: Browser doesn't gracefully quit at shutdown or restart
I think I reproduced this bug with my Linux yesterday.
I'll attach a compressed tar with the appropriate processes from proc tree;
don't know if it can help you.
I think this bug has a greater severity than expected.

In Win95 sometimes my system hangs, I think this is caused by mozilla and by
this bug.
I think this bug somehow is connected with a "non-closed thing". This causes
that mozilla isn't closed in the right way and somehow -in some special cases-
memory usage exceed and somehow could hang mozilla.

Well, I dont know exactly how to reproduce this problem. But clicking some of
this paid start sites caused anormal much of such problems. 
This makes me think of the following maybe connected to this problem:
Flash Plugin?
Many Pop-Ups (maybe opened by Tabs)?
Many banners and graphics?
Don't know whether this hang is really connected to this bug.
Open new bug 122485
I think this bug may be caused as following:
A page opens a pop-up, but then for some reason it is not opened - maybe it
waits for sth; what it is I don't know - a plugin?, a dns lookup?, ????

As I described in comment #19 I could reproduce this in Linux. Should we set
Platform to all?

I think this bug causes performance problems?!? Keyword perf ??????
Reset Keyword pp?
Please not that we have to make sure the solution to this bug also handles the 
situation described in bug 100874 (which I'm going to close as a duplicate).  
That bug says that we don't properly shut down when the user does Ctrl-Alt-Del, 
selects Mozilla, and chooses "End Process."

I don't know if that sends the same WM_ messages; we may need to look for 
additional ones (and handle them the same way).
*** Bug 100874 has been marked as a duplicate of this bug. ***
Comment #23 makes me thinking of an interesting question!
What happens to this bug when you turn on quick launch?!?!?!?
Is it possible to make mozilla don't stop when you click Icon/Exit mozilla?!??!
At the moment I can't produce this!
The report in bug 100874 only occurs sometimes (not sure when).  It is similar
to reports that you get the same "not responding" alert when shutting down (bug
100319); only happens in certain cases.
I'm not sure that this is related. I'm using a fairly slow computer, only a K6-2
at 381Mhz, running Windows 98.  When I exit out of Mozilla completely, and then
very quickly double-click on my Mozilla desktop icon/shortcut, Mozilla does not
restart. I have to wait several seconds, and then double-click the icon. It is
almost as if Mozilla has to completely exit for it to begin to start up again.
I've seen this for a few weeks now, and also today using Build ID: 2002020103.
Blocks: 34229
Well, this bug exists on every Windows and obviously on Linux (I reproduced it
severeal times), so I would change OS to all. (Only submitter or owner can do
this! So, .......) Shall we let pp in (I don't know about 
Mac (what does comment #1 mean? If this means we find it on Mac we should delete
Keyword pp))

I think we should give this bug a higher priority because mozilla needs a lot of
memory even when it is closed and I think it's also a performance problem while
running!

The memory when Mozilla has ended (from /proc on Linux!):
Name:   mozilla-bin
State:  S (sleeping)
Tgid:   3956
Pid:    3956
PPid:   3951
TracerPid:      0
Uid:    1005    1005    1005    1005
Gid:    0       0       0       0
FDSize: 1024
Groups: 0 
VmSize:    95516 kB
VmLck:         0 kB
VmRSS:     50484 kB
VmData:    72016 kB
VmStk:       144 kB
VmExe:       240 kB
VmLib:     18336 kB
SigPnd: 0000000000000000
SigBlk: 0000000080000000
SigIgn: 8000000000001000
SigCgt: 00000003800124f8
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
I got this error again two times a moment ago and looked at the libraries used
(via /proc/.../maps).
The only library used in both times over the standart is 
/usr/local/mozilla/components/libwallet.so. 
Is this the form manager?
nominating
Keywords: nsbeta1
Blocks: 123633
Blocks: 100319
I reproduced this bug a moment ago with my Linux and thought it would be a good idea to look what gdb says to the running process. Well, I have no experience with it, but I thought it would be a good idea to use gdb /usr/local/mozilla/mozilla-bin 12224.After that I typed bt (backtrace!) and got the following(gdb) bt#0  0x405b5b71 in __poll (fds=0xbef6148, nfds=31, timeout=-1)    at ../sysdeps/unix/sysv/linux/poll.c:52#1  0x403d305b in g_main_poll (timeout=-1, use_priority=0, priority=0)    at gmain.c:1034#2  0x403d28ef in g_main_iterate (block=1, dispatch=1) at gmain.c:808#3  0x403d2d64 in g_main_run (loop=0x8135ac0) at gmain.c:935#4  0x402c9c0e in gtk_main () at gtkmain.c:524#5  0x408815c4 in NSGetModule ()   from /usr/local/mozilla/components/libwidget_gtk.so#6  0x406c239e in NSGetModule ()   from /usr/local/mozilla/components/libnsappshell.so#7  0x0804fe49 in main1 ()#8  0x08050697 in main ()#9  0x40504978 in __libc_start_main (main=0x8050568 <main>, argc=1,     ubp_av=0xbffff784, init=0x804bfa4 <_init>, fini=0x8051af0 <_fini>,     rtld_fini=0x4000b5c0 <_dl_fini>, stack_end=0xbffff77c)    at ../sysdeps/generic/libc-start.c:129(gdb) I look if I find a other interesting function, and if I found one I'll report the output, or if you're interested in executing a gdb command, just ask!
Sorry for this unreadable Comment #31; I had this error again by the following:
Open www.6to.de, doing nothing, "this plugin needed" opened and I don't close it
explicitly, but close mozilla.
Here again the backtrace(hope better):
#0  0x405b5b71 in __poll (fds=0x88e1138, nfds=38, timeout=-1)
    at ../sysdeps/unix/sysv/linux/poll.c:52
#1  0x403d305b in g_main_poll (timeout=-1, use_priority=0, priority=0)
    at gmain.c:1034
#2  0x403d28ef in g_main_iterate (block=1, dispatch=1) at gmain.c:808
#3  0x403d2d64 in g_main_run (loop=0x8127a90) at gmain.c:935
#4  0x402c9c0e in gtk_main () at gtkmain.c:524
#5  0x408815c4 in NSGetModule ()
   from /usr/local/mozilla/components/libwidget_gtk.so
#6  0x406c239e in NSGetModule ()
   from /usr/local/mozilla/components/libnsappshell.so
#7  0x0804fe49 in main1 ()
#8  0x08050697 in main ()
#9  0x40504978 in __libc_start_main (main=0x8050568 <main>, argc=1, 
    ubp_av=0xbffff784, init=0x804bfa4 <_init>, fini=0x8051af0 <_fini>, 
    rtld_fini=0x4000b5c0 <_dl_fini>, stack_end=0xbffff77c)
    at ../sysdeps/generic/libc-start.c:129
I played a bit more with gdb and found a little bit more information:
I don't know whether it could help anybody, but because reproducing this bug is
not easy, I'll post it here (just select what's useful): (bt is same as above)

(gdb) up
#1  0x403d305b in g_main_poll (timeout=-1, use_priority=0, priority=0)
    at gmain.c:1034
1034    gmain.c: No such file or directory.
        in gmain.c
(gdb) display
33: {<text variable, no debug info>} 0x405b5b20 <__poll> = {
    <text variable, no debug info>} 0x405b5b20 <__poll>
32: __poll = {int (struct pollfd *, nfds_t, int)} 0x405b5b20 <__poll>
31: *__poll = {int (struct pollfd *, nfds_t, int)} 0x405b5b20 <__poll>
30: __poll = {int (struct pollfd *, nfds_t, int)} 0x405b5b20 <__poll>
27: must_emulate = 0
26: fd_array = (GPollFD *) 0x8be59f0
25: fd_array = (GPollFD *) 0x8be59f0
22: pollrec = (GPollRec *) 0x7fffffff
20: priority = 0
19: use_priority = 0
18: *poll_records = {priority = 0, fd = 0x403b973c, next = 0x80d7aa0}
17: poll_records = (GPollRec *) 0x80d7a88
16: wake_up_pipe = {14, 15}
15: npoll = 34
14: i = 34
13: pollrec = (GPollRec *) 0x7fffffff
9: pollrec = (GPollRec *) 0x7fffffff
8: *fd_array = {fd = 6, events = 1, revents = 0}
7: fd_array = (GPollFD *) 0x8be59f0
6: i = 34
(gdb) down
#0  0x405b5b71 in __poll (fds=0x8be59f0, nfds=34, timeout=-1)
    at ../sysdeps/unix/sysv/linux/poll.c:52
52      ../sysdeps/unix/sysv/linux/poll.c: No such file or directory.
        in ../sysdeps/unix/sysv/linux/poll.c
(gdb) display
33: {<text variable, no debug info>} 0x405b5b20 <__poll> = {
    <text variable, no debug info>} 0x405b5b20 <__poll>
32: __poll = {int (struct pollfd *, nfds_t, int)} 0x405b5b20 <__poll>
31: *__poll = {int (struct pollfd *, nfds_t, int)} 0x405b5b20 <__poll>
30: __poll = {int (struct pollfd *, nfds_t, int)} 0x405b5b20 <__poll>
28: errno_saved = 4
27: must_emulate = 0
18: *poll_records = {priority = 0, fd = 0x403b973c, next = 0x80d7aa0}
17: poll_records = (GPollRec *) 0x80d7a88
16: wake_up_pipe = {14, 15}
1: timeout = -1
(gdb)
nsbeta1+ per ADT triage team
Keywords: nsbeta1nsbeta1+
Dan, can you update this bug with your progress?  It blocks bug 100319, which we
need for turbo/machv.
Whiteboard: [adt1]
ADT1
Dan, any eta on this?
Why is this ADT1?  It looks like the bug this blocks has been marked nsbeta1-
and moved to 1.2Alpha?  Can we lower the impact.
Attachment #81729 - Flags: needs-work+
Comment on attachment 81729 [details] [diff] [review]
First stab at patch to fix this

I've tested this out and it works fine on WindowsXP.  I've had some issues
testing on Win98 and Win95 but that's probably unrelated to my code.

Now looking for reviews, etc.
Attachment #81729 - Flags: needs-work+
Finally taking from Dan.
Assignee: danm → law
Status: ASSIGNED → NEW
WFM (without any patches) with build 2002-04-29-branch and Quicklaunch, on WinNT

In fact, I've never noticed this problem.  Was I supposed to do something
besides leave a browser window open during system shutdown?  Is it possible that
this bug is merely delaying the shutdown rather than hanging it or causing an
error prompt?  From reading the previous comments, it wasn't clear. 
As the initial comment implies, we truly don't shutdown "gracefully" when the 
user shuts down Windows (or logs off).  Older versions of Windows (I think) 
responded to that by putting up an alert about "that stupid app doesn't want to 
shut down, go ahead and kill it?" (it may be that this only appears in certain 
situations, not all).

Normally, under Win2K (and WinXP), the OS just closes all the windows and kills 
the process.  That in itself is a bug, because we don't catch cases where we 
have open (and modified) Composer windows or mail message compose windows.  We 
don't prompt the user for whether to save that info.

So, it really doesn't "wfy" (work for you).  It just seems like it, since the 
default behavior is indistinguishable from what should happen in the particular 
case you tried.  Try an open Composer document and see if the right thing 
happens :-).
One thing I want to mention before people go off and try to test this in debug
builds:

Windows will not send WM_QUERYENDSESSION to console applications.  By default, a
debug build of Mozilla is a console application (that's how you can see the
console log right in the session where you started it up).  So to test this, you
must build a non-console application.  You can do that by setting the
environment variable MOZ_WINCONSOLE=0 when you build in mozilla/xpfe/bootstrap.

We could detect system logout/shutdown as a console app, but that notification
does not provide a means of cancelling logout/shutdown.  So we'd have to do
something like put up a dialog warning the user that "Pressing Cancel when asked
to save/don't save/cancel a Composer or mail compose window won't really cancel
and your work will be lost.  Always Save if you don't want to lose it."  But
since this only happens with debug builds and nobody in their right mind would
do work that they cared about losing using a debug build, I don't think this is
necessary.
Comment on attachment 81729 [details] [diff] [review]
First stab at patch to fix this

r=sgehani  

Please add a comment on what GetChromeUrlForTask() is really doing (alluding to
the fact that the method name is a misnomer).
Attachment #81729 - Flags: review+
Blocks: 143047
Comment on attachment 81729 [details] [diff] [review]
First stab at patch to fix this

looks good to me, and if there's anyone who knows about this it's you.
sr=blake. but please remove the return after else?
Attachment #81729 - Flags: superreview+
> but please remove the return after else?

Can you explain this comment, please?  I didn't add any extraneous returns, and 
I don't think there were any there before, so I'm not sure what I'm supposed to 
remove.
+        if ( rv == NS_ERROR_ABORT ) {
+            // User cancelled shutdown/logoff.
+            return FALSE;
+        } else {
+            // Shutdown/logoff OK.
+            return TRUE;
+        }

That 'else' after the return is unnecessary. It doesn't bother me too much but
many of the other reviewers request that it be fixed, so I figured I'd jump on
the bandwagon.
So it should [sic] be:

if ( rv == NS_ERROR_ABORT ) {
    return FALSE;
}
return TRUE;

?

I've got a better idea:  "Reviewers" should stop wasting their time trying to 
impose some asinine set of rigid code style rules and stick to finding the 
fucking bugs.

No offense to you, Blake.  Don't let the dark side win you over.
fixed
Keywords: adt1.0.0
This isn't the right fix.  We should be responding to WM_ENDSESSION, not
WM_QUERYENDSESSION.  The WM_QUERYENDSESSION message is just Windows asking if
it's OK to shut the application down.  It doesn't actually shut things down
until WM_ENDSESSION.
We need to handle WM_QUERYENDSESSION so that we can stop the logoff/shutdown if 
the user says "Cancel" when Composer or Mail Compose ask them what to do with 
their open Composer/Mail-Compose windows.

If the user doesn't say Cancel, then -killAll will have shut us down and we 
won't ever see WM_ENDSESSION.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Huh?  You'll never get a WM_ENDSESSION without getting a WM_QUERYENDSESSION
first.  The WM_QUERYENDSESSION processing should handle things like Composer
asking to save changes.  If the user says cancel, return false and that's the
end of it.  If the user says yes or no, return true and then the app will get
WM_ENDSESSION.
Wow, you sound pretty disproportionately angry over a suggestion that would have
taken two seconds to fix.  Have you considered taking some time off?
adding adt1.0.0+.  Please get drivers approval and checkin to the 1.0 branch.
Keywords: adt1.0.0adt1.0.0+
>Huh?  You'll never get a WM_ENDSESSION without getting a WM_QUERYENDSESSION
>first.

Yes, I'm in agreement with that.  My reply implied it, I hope.

>The WM_QUERYENDSESSION processing should handle things like Composer
>asking to save changes.

Again, I agree.  And that's exactly what the code does, which is evident if you 
examine the implementation of the "-killAll" cmd line handler (or trust the 
comment in the patch).

>  If the user says cancel, return false and that's the
>end of it.

Yes.  Again, this is exactly what the code does.  And it's what the comments in 
the code says it will do.

>If the user says yes or no, return true and then the app will get
>WM_ENDSESSION.

Yes.  *Unless* the app is no longer running.  Which is the case for us because 
of the way the "-killAll" command handler works (it will terminate the app 
after closing all open windows, unless the user cancels).  Theoretically, it 
might be marginally better to delay closing the other windows till 
WM_ENDSESSION, in case some other application cancels the logoff/shutdown.  But 
it would be relatively difficult to modify the logic of -killAll to do that and 
it isn't worth the time or trouble to do so.

Bottom line is that the code works as written, I believe.  I.e., it works the 
way you seem to be saying it *should* work.  Please clarify if you still 
disagree with that.

Here's the comment in the WM_QUERYENDSESSION handling:

+    // Invoke "-killAll" cmd line handler.  That will close all open windows,
+    // and display dialog asking whether to save/don't save/cancel.  If the
+    // user says cancel, then we pass that indicator along to the system
+    // in order to stop the system shutdown/logoff.

Isn't that exactly what you just said it should do?
>Wow, you sound pretty disproportionately angry over a suggestion that would 
>have taken two seconds to fix.

First, you seem to be confusing my simple irritation for anger.

Second, there is nothing broken, so your whole point is moot.

Third, it's not the 2 seconds to "fix" [sic] it, it's the time reviewers waste 
nitpicking this stuff, and the real bugs they miss because they're too hung up 
on this kind of stuff.  Time spent disavowing them of such foolishness is well-
spent, IMHO.

>Have you considered taking some time off?

All the time; but I don't suspect I'd come back more easily brainwashed.
*** Bug 145469 has been marked as a duplicate of this bug. ***
*** Bug 131141 has been marked as a duplicate of this bug. ***
Priority: P3 → P2
Whiteboard: [adt1] → [adt1 rtm]
Bill: I guess I misunderstood the scope of killAll.  I thought that it was
responsible only for ending the app task, I didn't realize it also handled
closing all open windows and the subsequent save/dontsave/cancel prompting.  The
name lead me to believe that it was something more immediate.
changing to adt1.0.1+ for adt approval for checkin to the 1.01 milestone. 
Please get drivers approval before checking in.
Keywords: adt1.0.0+adt1.0.1+
Keywords: mozilla1.0.1
please checkin to the 1.0.1 branch ASAP. once there please remove the
mozilla1.0.1+ keyword and add the fixed1.0.1 keyword.
Attachment #81729 - Flags: approval+
Has anyone checked whether this will cause problems if someone cancels shutdown
through another application other than Mozilla?
From MSDN's info on WM_QUERYENDSESSION
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/shutdown_83se.asp):

Windows NT/2000/XP: When an application returns TRUE for this message, it
receives the WM_ENDSESSION message and it is terminated, regardless of how the
other applications respond to the WM_QUERYENDSESSION message.

Windows 95/98/Me: After all applications return TRUE for this message, they
receive the WM_ENDSESSION and they are terminated. 


I guess that's why I was wondering about moving this to WM_ENDSESSION.  Not that
big a deal, I don't think.  If the user's on 9x then Moz will shut down if it
receivs the WM_QUERYENDSESSION message before the app that returns false.  The
NT way is the "new" way, so if we support that I think we're doing well enough.
From the URL you posted and
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/shutdown_13u6.asp)

Dean: I agree that the correct way to handle this is to wait for WM_ENDSESSION.
I believe that the way the SDK says to deal with this is how we should, and
users on Win95/98/ME might think its a bug in Mozilla that it is the only one
that closes when you hit cancel on an app. Although this fix is adequate for
now, I believe it might be good to alter the code in the future - when we aren't
on the verge of a new release - to follow the method the SDK laid out.
Therefore, I would agree with you if you opened a new low-priority bug about
fixing this. If you do - feel free to CC me.

Bill: If the creation of KillAll fails, DefWindowProc will return TRUE, saying
its ok to shut down the system. Is that behavior what you want?

<slightly offtopic> 
- Would it be better for KillAll to wait for the user to reply to all the dialog
boxes for Save/Dont save/Cancel before closing all the Mozilla windows? That
way, if a user hit cancel, he wouldn't lose any other windows, such as browser
windows that might have form data he didn't think about before shutting down. 
- Also, if there are no compose windows to save, wouldn't it be nice to give the
user the option of cancelling anyway? Maybe by asking him if he is sure he wants
to exit Mozilla?
</slightly offtopic>
verified on trunk builds (Mozilla and commercial- NT, 2k and 98)2002053106
Status: RESOLVED → VERIFIED
fix landed on branch

re: comment 65

>I believe that the way the SDK says to deal with this is how we should, and
>users on Win95/98/ME might think its a bug in Mozilla that it is the only one
>that closes when you hit cancel on an app.

I think the real world the distinction is lost on just about everybody.  I 
doubt that there is a single Windows application that doesn't close all its 
windows when it gets WM_QUERYENDSESSION.  The reason is the same reason that we 
do: the windows already have logic that asks "save, don't save, cancel?" when 
you close dirty windows.  The only way to *use* that code is to close the 
window.  So the net result is that the windows are all closed after you're done 
asking.  If some app down the line says Cancel, you can't go back in time and 
unclose the windows that have already been closed.

>If the creation of KillAll fails, DefWindowProc will return TRUE, saying
>its ok to shut down the system. Is that behavior what you want?

Yes.  We can't block Windows shutdown/logoff just because we've got a bug in 
our code (or a screwed up installation).

>Would it be better for KillAll to wait for the user to reply to all the dialog
>boxes for Save/Dont save/Cancel before closing all the Mozilla windows?

Maybe.  Is it worth the effort it would take to implement?  Probably not.

>Also, if there are no compose windows to save, wouldn't it be nice to give the
>user the option of cancelling anyway? Maybe by asking him if he is sure he 
>wants to exit Mozilla?

Since we don't even ask them that if they choose File|Exit, I'm not sure why 
we'd do it when they logoff Windows.  It's not like the user is going to lose 
anything (save some unsubmitted form data; but there's a bug on that).  Hell, 
we got all the way to Mozilla1.0 without people complaining too much about us 
closing their unsaved Composer/Mail windows.
using branch build for 6/7 
Blocks: 212316
It appears that killall isn't "cleanly" unloading Mozilla.   I'm making this
assumption by the symptoms of bug 212316

I see the Javascript function goQuitApplication to cleanly unload Mozilla, but
is there a C++ equivalent?    Or is the best solution here to call that
JavaScript function from the C++ code handling WM_QUERYENDSESSION?
Product: Core → Mozilla Application Suite
just to mention newer requirements for Windows Vista and above while 
handling  WM_QUERYENDSESSION & WM_ENDSESSION (and WM_CLOSE) 
see Bug 1323007 Comment 3 ( https://bugzilla.mozilla.org/show_bug.cgi?id=1323007#c3 )
, and Bug 1270666 ( https://bugzilla.mozilla.org/show_bug.cgi?id=1270666 )
You need to log in before you can comment on or make changes to this bug.