312135 - Cannot terminate thunderbird.exe

Status: RESOLVED FIXED

(Thunderbird :: General, defect, P2)

Description

[Jerry Baker]

20051010 trunk

If I kill thunderbird while a new mail envelope is showing in the system tray,
thunderbird doesn't actually exit. The window goes away but the process never dies.

Comment 1

[Jerry Baker]

It turns out that Thunderbird cannot be terminated at any time after a new mail
icon has been displayed regardless of whether it is currently displayed or not.

Comment 2

[Jerry Baker]

This appears to be WFM with 20051011, but I will wait a day or two to make sure
it doesn't come back.

Comment 3

[David :Bienvenu]

this happens to me with my debug trunk build if I bring up the compose window. I
don't have to send mail, or get a new mail notification. Just bringing up the
compose window and shutting down hangs.

Comment 4

[Jerry Baker]

I see this as well in the 20051011 nightly.

Comment 5

[Wayne Mery (:wsmwk)]

I'm seeing it version 1.6a1 (20051008) so it's at least that old. After the
resources/processor/cpu bug was fixed this shutdown issue continued.  

Comment 6

[Jerry Baker]

This is still a problem: 20051022 trunk.

Comment 7

[Ray Booysen]

This is still appearing on 20051025 trunk.  Is this not a blocker?

Comment 8

[Ray Booysen]

Apologies for the bugspam.  Clicked testcase by accident.

Comment 9

[David :Bienvenu]

if you turn off compose window recycling, by setting "mail.compose.max_recycled_windows" to 0, then shutdown works fine for me. The nsAppStartup::ExitLastWindowClosingSurvivalArea code which decrements mConsiderQuitStopper never gets called when compose window recycling is on, when the compose window is closed. So nsAppStartup never things we need to shut down. That code doesn't look particularly new, so I suspect something else is going on...

Comment 10

[Benjamin Smedberg]

I think that the code in bug 310076 was a necessary change, and we should look at how to make the cached compose window not affect the considerquitstopper. What method do we use to "hide" the cached compose window? Perhaps windows hidden in such manner should fire a matched set of xul-window-hidden and xul-window-shown notifications or something like that...

Comment 11

[Scott MacGregor]

benjamin, would this effect the 1.8 branch? Some form of 310076 went into the branch. I haven't noticed it on the branch but maybe I've just been lucky. 

Comment 12

[Benjamin Smedberg]

No, this is trunk-only, caused by the "scary version" patch in bug 310076.

Comment 13

[David :Bienvenu]

We basically register/unregister the window with the window mediator, and SetVisibility() on the base window.

http://lxr.mozilla.org/mozilla/source/mailnews/compose/src/nsMsgComposeService.cpp#1228

nsXULWindow::SetVisibility() gets called even when the window is already visible, from what I can tell, e.g., on focus changes. So it might need to get smarter. I'm not sure you're going to be able to use SetVisibility as an access point. But perhaps the window mediator calls could trigger a notification? Or is the window mediator getting deprecated somehow?

Comment 14

[David :Bienvenu]

I guess the window mediator calls wouldn't be helpful unless they could somehow distinguish between a window being destroyed and a window getting hidden, and between a window getting created and a window getting shown after being hidden. Off the top of my head, I don't know what interfaces are frozen, so I don't know if we can add some methods for this particular situation. We could always invent a new notification for the compose window to call, but it would be a lot nicer to hide this detail from the app.

Comment 15

[Benjamin Smedberg]

There aren't really any frozen interfaces to worry about here. I switched from using windowmediator to determine when to shut down the app because of the issues with non-window considerquitstoppers never shutting down the app. It could be possible to move the "xul-window-registered" and "xul-window-destroyed" notifications from nsXULWindow and the appshellservice into the windowmediator register/unregister pair, but the patch I'm going to attach is a decent hackaround while I examine the implications of that change.

Comment 16

[Benjamin Smedberg]

Attachment: Fire xul-window notifications for the cached compose window

Comment 17

[David :Bienvenu]

Comment on attachment 200880 [details] [diff] [review]
Fire xul-window notifications for the cached compose window

great, thx, r/sr=bienvenu with one nit:

+  nsCOMPtr<nsIObserverService> obs
+    (do_GetService("@mozilla.org/observer-service;1"));
+  NS_ENSURE_TRUE(obs, NS_ERROR_FAILURE);
+

why not use the rv that do_GetService will provide, and NS_ENSURE_SUCCESS(rv, rv) instead of dropping the particular error?

Comment 18

[Benjamin Smedberg]

ok, fixed on trunk with rv-check instead of null-check (I generally prefer null-check for no good reason).

Comment 19

[Ray Booysen]

Still seeing this on 20051027.

Comment 20

[Mike Cowperthwaite]

(In reply to comment #19)
> Still seeing this on 20051027.

Really?  I've exited 1.6a1-1101 several times today, including one time where I specifically opened a compose window before exiting to test this, and it's fully unloaded every time.

Jerry Baker, are you still seeing the problem?

Comment 21

[Jerry Baker]

No, I am not.

Comment 22

[David :Bienvenu]

I haven't had it fail to exit since the fix was checked in.

Comment 23

[Ray Booysen]

Mike, I don't see this with 1101 anymore.  It seemed to be a once off.

Comment 24

[Mike Cowperthwaite]

v

Comment 25

[Jerry Baker]

It's back, and with a vengeance. After opening a compose window thunderbird.exe sometimes crashes (TB11595137Y), otherwise becomes totally unresponsive. Cannot switch folders, or do anything. This regressed between 20051106 and 20051107 trunk.

Comment 26

[Jerry Baker]

The checkin for bug 315127 looks suspicious.

Comment 27

[Benjamin Smedberg]

Jerry, that bug is not this bug. Please keep things simple by filing new bugs on new issues.

Comment 28

[Jerry Baker]

See bug 315560.