379737 - Compose window doesn't close properly when on a different virtual desktop using "Enhanced Virtual Desktops"

Status: RESOLVED INCOMPLETE

(Thunderbird :: Message Compose Window, defect)

Description

[Brandon Checketts]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Build Identifier: 2.0.0.0 (20070326)

After composing a message and hitting 'send', I switch to a different virtual desktop.  When returning to the original desktop, the message has been sent, but the compose window hasn't been destroyed properly.  It still has the borders and title bar of the window.   I'm unable to manipulate that window in any way.  Closing the main Thunderbird app does destroy the window.

Virtual Desktop software is 'Enhanced Virtual Desktops' V4.6.187

Reproducible: Always

Steps to Reproduce:
1. Create new message
2. Hit send
3. Change virtual desktops while the message is sending
4. Return the the original desktop to see the old message still partially there
Actual Results:  
Border of the Compose window is still on the screen.  It is not selectable or doesn't respond to clicks in any way

Expected Results:  
The compose window should close

Comment 1

[Koobs]

Confirming with identical reproduction steps in:

Mozilla Thunderbird: 2.0.0.3 / 2.0.0.4
Operating System: Windows XP Service Pack 2
VD Software: Virtual Dimension (http://virt-dimension.sourceforge.net/)

Virtual Dimension employs one of 3 user-selected methods for achieving the virtual desktop functionality: window.hide, minimize and move methods.

I have tested and can confirm symptoms exist with all 3 methods.I was hoping it was going to be window.hide only ;)

The main Thunderbird window is completely responsive and usable, whereas the Compose dialog is selectable, but not responsive.

The regression was introduced in one of last ~2-3 releases, not including 2.0.0.4

Comment 2

[Koobs]

Gah, make that confirmed in 2.0.0.4 and all the way back to 2.0 Beta 2 :)

Comment 3

[Koobs]

Further information:

- Account in question is a POP3/SMTP with AUTH account, non-SSL.
- Confirming Ivan's comment in bug 300012

Opening a new compose window does indeed unhang/refresh/repaint the hung compose window (tested/confirmed twice)

Comment 4

[James Cameron]

I am seeing this on a standard XP desktop after an upgrade to 2.0.0.4. The description of the issue is identical. If I select File->New->Message the zombie window is resurrected and functions correctly. No entries are appearing in the error log. 

Not sure if it is related but the time the sending progress dialog is open appears to be significantly longer with 2.0.0.4. There may be a timing issue in the window close notification logic.

Comment 5

[Robert]

Same here, on XP.

Virtual desktop software used is MS Terminal Services.

Only title bar remains. When clicking on the minimize, restore or close button n error beep sound is made.

(I am still able to move the window over to my other monitor by using monitor management software, Ultramon, so it does not seem to be a hardware redraw issue or somehting)

Comment 6

[Wayne Mery (:wsmwk)]

does this look to you like a duplicate of bug 235019?

and, is this even fixable in thunderbird, or must the solution come from Virtual Dimension?  

Comment 7

[Robert]

Maybe I'm a newbie in debugging logics (no sarcasm intended), but in my case (see two posts above), I indicated that the Virtual desktop software I use to reproduce the error is MS Terminal services, which I guess is not related to Virtual Dimension, so I think the issue should be addressed in TB.

The only other variable I see is that a lot people mention IMAP, which I use as well, but hey, I reckon that does not definitive narrow down the search :)

Comment 8

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #0)
> Reproducible: Always
> Steps to Reproduce:
> 1. Create new message
> 2. Hit send
> 3. Change virtual desktops while the message is sending
> 4. Return the the original desktop to see the old message still partially there
> Actual Results:  
> Border of the Compose window is still on the screen.  It is not selectable or
> doesn't respond to clicks in any way

Phenomenon of actual result(zombie compose window) is same one as Bug 347693 and Bug 380275, and already mentioned Bug 235019 too(condition is still unclear though).

To Brandon Checketts(bug opener), Koobs, James Cameron, Robert:       
You all say "Reproducible: Always". Really always when above operations?
Isn't similar condition to Bug 380275 involved?

Comment 9

[James Cameron]

After I deleted and recreated the msf files this issue stopped occurring. Up to that point it was reproducible every time. The backups of the msf files are large and contain commercially sensitive information so unfortunately I can not send them to this list.

Unlike Bug 380275 I did not have any memory optimizer or virtual desktop running and it did not appear to be timing related ie close window quickly. It also did not appear to be a result of a memory leak because it happened if the first thing I did in th session was create a new message.

Hope this helps.   

Comment 10

[Brandon Checketts]

I've tested again today and this issue appears to be resolved now running Thunderbird 2.0.0.6 (20070728) with same version of EVD.  I'm unsure exactly which version upgrade fixed it and can go back and reinstall old versions if anybody things that would be worth the time.

Comment 11

[Wayne Mery (:wsmwk)]

Thanks Brandon.  => WFM per reporter.

Brandon/Koobs Not necessary but if you are interested in doing the exercise, please post back what version of TB it got fixed in.

Comment 12

[Robert]

Sorry to say, but I've just have had the zombie window again. I'm running version 2.0.0.6 (20070728) too. Yet I find it hard to reproduce.

Comment 13

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #12)
> I've just have had the zombie window again.

Question to clarify.
To Robert:   
Your problem is same as next phenomenon which was described in Comment #0 by bug opener?
> After composing a message and hitting 'send', I switch to a different virtual desktop.  
> When returning to the original desktop, the message has been sent,
> but the compose window hasn't been destroyed properly.
Or problem when other condition?

Please see Bug 347693 Comment #6. Virtual desktop case looks to be (3) of Bug 347693 Comment #6, "longer processing time to close compose window after send completion, than other module's logic expects".

Comment 14

[Robert]

No the phenomenon is not the same as <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=379737#c0">Comment #0</a>, as it only occurs upon send, not upon a quick open and close of a window.

I'm also not running process explorer, although I have it on my PC, but is does not seem related.

An additional experience it that it seem to occur when email is sent from my secondary monitor. Any time another zombie is created, it replaces the previous zombie, and sometime when send in a mail does not result in a zombie window, it even removes the zombie.

Another issue that might make this unrelated to the original issue, it that I'm running multiple monitor management software; Ultramon, that might cause the problem. Once I've killed it, the zombie does not appear again.

Sorry to complicate things.

Comment 15

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #14)
> An additional experience it that it seem to occur when email is sent from my secondary monitor.
> I'm running multiple monitor management software; Ultramon, that might cause the problem. 
> Once I've killed it, the zombie does not appear again.

No "Virtual Desk top", but "mutiple monitor"+"Ultramon" sounds to produce similar situation ("longer close time of compose window" than "close request logic when 'mail send completion').
Re-open in order to avoid loss of these cases. 

Comment 16

[WADA:World Anti-bad-Duping Agency]

Robert seems to have opened separate Bug 400377 for phenomenon when "mutiple monitor"+"Ultramon" case, in order to avoid confusion.

Comment 18

[Ivar Snaaijer]

I have this issue for quite some time, but I also have recycled my config files from every version I have used so far, starting with Mozilla. The same goes for most of my mail files. I tend to keep stuff.
I use IMAP and POP, mailing is always done using SMTP, most of these connections are TLS. I normally reload all IMAP from the server after a migration. 
I also exchange my settings and mail files with my Linux box (Currently Suse 10.2) if the necessity rises. Therefore I expect all to be full of clutter that might be remotely related to this issue (as James in #9 implies).