347693 - Closing cached compose window quickly turns it into a zombie

Status: RESOLVED WORKSFORME

(MailNews Core :: Composition, defect)

Description

[Andrew Schultz]

With linux seamonkey trunk build 2006080609, if I 

1. open a compose window
2. close it
3. open a second window (recycled)
4. close it very quickly
[repeat 3 & 4 until you hit the bug, happens at least 1 time in 3 for me]

I get a zombie window.  I can't close it with Ctrl-W (I get a JS exception) but  closing the window via the X does work.  In SeaMonkey, new composition windows after that are not recycled.  In Thunderbird, the mail window closes when I close the compose window.

Comment 1

[WADA:World Anti-bad-Duping Agency]

I frequently got Zombie compose window while re-creation test of Bug 389132, using "Process Monitor" (Tb 2.0.0.5 on MS Win-XP/Core2 Duo).
0. Auto-save=OFF, in order to avoid Bug 380275.
1. Select 100 mails in a local mail folder, then "Forward as Attachment"
2. Start "Process Monitor" and capture activity of thunderbird.exe
   http://www.microsoft.com/technet/sysinternals/utilitiesindex.mspx
3. Send Later
Window seems to be made wider by capturing of "Process Monitor".

Andrew Schultz, do you use multi-CPU(core)? Or single CPU?
Can you re-produce problem on single-CPU machine?

Comment 2

[Andrew Schultz]

I just have a single single-core CPU.  Are you asking if I see the problem I reported or the problem you described?

Comment 3

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #2)
> Are you asking if I see the problem I reported...
I asked about problem you reported, because comment poster of Bug 380275 Comment #11 said "Bug 380275 seems to be multiple CPU only problem".

Comment 4

[WADA:World Anti-bad-Duping Agency]

FYI.
Bug 235019 looks to be the oldest reports of zombie compose window, although re-creation procedure is not discovered yet by the bug.

Comment 5

[WADA:World Anti-bad-Duping Agency]

Bug 379737 is report when virtual desktop. Reporter says "Reproducible: Always".
Setting dependency of Bug 379737, Bug 380275 (and oldest Bug 235019) to this bug, for ease of search.

Comment 6

[WADA:World Anti-bad-Duping Agency]

Logic for "end of send" is in;  
http://lxr.mozilla.org/seamonkey/source/mailnews/compose/resources/content/MsgComposeCommands.js#202
> 202 var gComposeRecyclingListener = {
> 203   onClose: function() {
> 204(snip)
> 255     var event = document.createEvent('Events');
> 256     event.initEvent('compose-window-close', false, true);
> 257     document.getElementById("msgcomposeWindow").dispatchEvent(event);
> 258     if (gAutoSaveTimeout)
> 259       clearTimeout(gAutoSaveTimeout);
> 260   },
> 261 
> 262   onReopen: function(params) {
>(snip)
> 268     var event = document.createEvent('Events');
> 269     event.initEvent('compose-window-reopen', false, true);
> 270     document.getElementById("msgcomposeWindow").dispatchEvent(event);
> 271   }
> 272 };

It seems that contention, failure etc. between 'compose-window-close' process and other tasks:
(1) This bug
    'compose-window-close' event and task dispatch while task for
    'compose-window-reopen' event is in progress.
(2) Bug 380275
    'compose-window-close' event and task dispatch while task for autosave is
    in progress.
(3) My comment #1 case
    Slow clearTimeout(gAutosavetimeout) due to "Process Monitor", then 
    'compose-window-close' event and task dispatch while myself(ending process
    of mail send) is running.

If my guess is right, (3) can easily be be avoided by moving clearTimeout(gAutosavetimeout) before dispatchEvent(event).
For (2), check for "autosave is in progress" and one of next is required.
  a. Wait for termination of autosave
  b. Wait for end of canceling of autosave
  c. Cancel autosave, then wait for end of canceling of autosave
For (1), a kind of serialization between onClose: process and onReopen: process is required.

Comment 7

[WADA:World Anti-bad-Duping Agency]

Since patch for Bug 352310 has introduced flag of "gAutoSaving", check for "autosave is in progress" is easier than before.

Comment 8

[WADA:World Anti-bad-Duping Agency]

Other possibility in case (3).
If there is other works after diapatchEvent(and clearTimeout currently), or if termination of this task takes a while, or if delay in some works such as remmoveEventListener etc. exists, task for "compose-window-close" event may be interfared. In this case, waiting for complete mail send task termination is required in "compose-window-close" event task.

Comment 9

[Steve]

Update: Scenario:

[1] zombie window appears
[2] launch new compose window
[3] close new compose window
[4] neither compose nor zombie window remains

It seems like launching a new compose window somehow overrides or 'takes over' the zombie window. I discovered this technique by accident. Much faster than closing and relaunching Thunderbird.

FYI: WinXP SP2 user, Thunderbird v2009.

Comment 11

[Steve]

FYI: Bug persists in TB 2.0.0.14

Comment 12

[Antonio Freixas]

FWIW: My wife has the same problem. TB 2.0.0.18. What's interesting is that we recently went on a trip and shared the same laptop. I copied her TB setup and mine to the laptop. Using exactly the same copy of TB, she had the zombie compose window and I didn't. We used the same virus checker, firewall, etc.

Comment 13

[Steve]

Confirming: Bug persists in TB 2.0.0.18.

Launching new compose window when zombie window observed, then closing new compose window. still eliminates both zombie and new compose window, and is still the fastest workaround.

Comment 14

[Herre de Jonge]

Confirm: Bug persists in TB 2.0.0.19
Platform: Windows Vista (Business SP1)

Although the workaround has allways worked and still works, this bug is still a bother.

Comment 15

[Steve]

Confirm: Bug persists in TV version 2.0.0.21 (20090302)
Platform: WinXP SP3
Workaround: Launching new compose window when zombie window observed, then closing new compose window still eliminates both zombie and new compose window.

Comment 16

[Michael]

Confirm:  Bug persists in my TB v2.0.0.21
Platform:  WinXP SP3
Workaround:  I'm using the same workaround as the others...  Open a new compose window and then close it in order to get rid of the zombie window and the newly created compose window.

I'm using a Dell D430 laptop and I use a dual monitor setup, via the built in graphics tools, when I'm in the office.  Although the problem happens whether I'm using the dual monitor setup or just stand-alone.  I've tried compacting folders, deleting *.msf files, playing with various screen resolutions - nothing seems to correct.  Unfortunately, I can't get the start of the zombies to any single day or event.  I've been dealing with this for about a week.

Comment 17

[Wayne Mery (:wsmwk)]

at this point, TB2 is not so interesting - if for no other reason than it isn't going to get fixed there.

Far more interesting is testing to see whether it happens in TB3 **.
As might be searching bugzilla to related bugs.

** http://www.mozillamessaging.com/en-US/thunderbird/early_releases/
   backup your profile before testing

Comment 18

[Wayne Mery (:wsmwk)]

ajschult, can you still reproduce?

Comment 20

[Steve]

I don't have access to a spare machine to test TB3 beta releases in an attempt to replicate the problem. 

Nor can I afford to risk potential problems by installing TB3 beta releases on the machine I depend on every day

So, I'll be looking for the issue once the "public" version of TB3 is released.

Comment 21

[Andrew Schultz]

This got fixed in SeaMonkey by the switch to toolkit (I see it in a 20070928 xpfe build and not a 20070929 toolkit build).  Not sure what that means for TB...

Comment 22

[Steve]

I've moved to TB3. No longer a problem for me. Removing cc.

Comment 23

[Wayne Mery (:wsmwk)]

=> WFM then