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.

Mac bug is P2, marking this one P2.

Still a problem with the 1999102908 builds under Windows...

targetting m13, p3. Does this still happen, perhaps on NT only? I haven't seen it on Win98 in a while.

Mass moving M17 bugs to M18

mass-moving all bugs to m21 that are not dofood+, or nsbeta2+

moving en masse all bugs that didn't get nsbeta3 nomination to "future" milestone

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).

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.

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)

*** Bug 111123 has been marked as a duplicate of this bug. ***

taking QA since turbo related

this bug has obviously morphed over the ages. anyway, over to a XP Apps component

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.

*** 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.

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.

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

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

Dan, can you update this bug with your progress? It blocks bug 100319, which we need for turbo/machv.

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.

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.

Finally taking from Dan.

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).

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?

> 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

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.

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.

>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. ***

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.

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.

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

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

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?

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 )