Closed Bug 380275 Opened 18 years ago Closed 13 years ago

Compose Window does not close after message has been sent (mail send while auto-save is in progress)

Categories

(Thunderbird :: Mail Window Front End, defect)

Product:
Thunderbird
Component:
Mail Window Front End
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: deeno.privat, Unassigned)

References

(Depends on 1 open bug)

Details

(Whiteboard: [closeme 2012-02-21])

Attachments

(1 file)

Same problem since update to Thunderbird 3.0.4
167.30 KB, image/jpeg
Details
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: version 2.0.0.0 (20070326) Compose Window does not close after message has been send and it shows up greyed out and all messy. cannot be closed or minimized. stays there like a ghost. only to be removed when i close/exit TB. when another window/application is on top and i minimize/close this then content of compose window keeps the content of that window "like a screenshot". looks like my graphic card messes up something or my desktop does not refresh properly it happens almost every time since i upgraded to TB V2 from 1.4 Reproducible: Sometimes Steps to Reproduce: 1. compose message 2. send message
Have you tried playing with the hardware acceleration settings of the graphics card?
Version: unspecified → 2.0
Are you using any memory optimiser software? If so, could this be a TB leak being inappropriately 'restored' by that? Please see possible example case, apparently very similar to this and resolved by disabling the optimiser, on Mozine forum. http://forums.mozillazine.org/viewtopic.php?t=553996#2910514
tried the hardware acceleration, nothing changed... i use FreeRamXP, disabled it, restarted, problem persists. (although the first two mails i send did not cause the problem, but after that every one...) That was yesterday... freeRamXP still disabled... problem persists this is really strange, as it appeared first time after upgrading to TB V2 additional software i use: Skype, intelProSetWireless, OpenOffice, Firefox (of course many more as well, but these are the ones always open)
I'm not sure if this (or these) are duplicates[*], or if these are even the same bugs, but, if so... I can probably confirm, Seamonkey 1.1.2 (and previous), on Windows NT 4.0. Sending a message results in a "Compose: (no subject)" entry appearing in the taskbar, unable to restore (de-iconify) or open. Using something to unhide windows, like <http://jthz.com/puter/software/Enumwin/>, I get the same stuff as the above (zombie window, un-refreshed contents). Opening a new compose window will turn the aforementioned "Compose: (no subject)" into a normal, functioning window, and can be closed. I write this because, switching from a dual CPU system to a "regular" computer, I never saw this happening. Started happening again, consistently, when I switched back to the dual CPU box, which probably suggests Some Generic Multithreading Issue (tm)? Any thoughts? [*] <https://bugzilla.mozilla.org/show_bug.cgi?id=379737> - Compose window doesn't close properly when on a different virtual desktop <https://bugzilla.mozilla.org/show_bug.cgi?id=347693> - Closing cached compose window quickly turns it into a zombie
this starts getting really annoying!!! in fact, i cannot work since a week because i am sending emails all the time with clients and have to restart TB all the time!!! i am really thinking of switching to MS... (and my stomach turns around when i think about it!) so please!!! do something!!!
I very wild guess, but try changing the value of mail.compose.max_recycled_win, maybe to 0, maybe to something else. (Options > Advanced > Config editor)
According to Bug 347693(pointed by Comment #4), procedure to create zombie compose window is "close compose window very quickly after open". When Auto Save(A in following part) is enabled, if confirmation(B) is also enabled, dialog is always displayed on Auto Save, and manual send while Auto Save usually won't occur. But when confirmation(B) is disabled, Auto Save is silently executed, except when charset change to UTF-8 is needed. Then, if "auto-save" and "manual send" followed by "send completion"(tries to close) are executed very closely, similar situation to "close very quickly after open" possibly occurs. To all problem reporters: Do you enable "Auto Save" with no confirmation dialog? (A) Tools/Options/Composition/General/Auto Save every MM minutes (B) Account Settings/Copies&Folders/Drafts and Templates/ Show confirmation dialog when messages are saved Note: If "Edit Draft", you can see "multiple draft mails" in thread pane of Drafts folder when Auto-Save=On. (Bug 382517) FYI. I enable confirmation(B) since Netscape 4 era(then since my first Mozilla M17), and I have no experience of zombie compose window while using many releases and nightlies of Mozilla&Seamonkey.
(A) auto save is on (every 5 min) (B) confirmation is not enabled what should i set them to? ...still strange, i never changed those values and TB never made problems before V2
(In reply to comment #8) > (A) auto save is on (every 5 min) (B) confirmation is not enabled > what should i set them to? To konstantinos(bug opener): If you don't feel annoyed or disturbed very much when dialog of each 5 minutes, please enable "confirmation dialog" and wait for completion of Draft save(if IMAP, it may take a while). Will frequency of zombie window be reduced? > ...still strange, i never changed those values and TB never made problems > before V2 I'm not sure, but problem such as Bug 382517 seems to be new in Tb 2.0(worse when trunk).
ok, i will check
I must say that this problem (which seems to be vague amongst the several possible bug reports here), for me, seemed only sometimes reproducible regardless of (A) autosave and (B) confirmation, for all of my mail accounts (meaning, "Compose: (no subject)" entry in the taskbar, unable to restore/maximize -- simply starting a Compose window as normal (CTRL+M) will work, since it's not showstopping or anything). (It almost sounded like, but not entirely, bug 307672, from what konstantinos reported.) Even so, it seems perhaps that perhaps a rogue modal dialog is attached somewhere, as doesn't appear to happen just by clicking 'send' (as opposed to using Ctrl+Enter, which may be detected more than once, or may continue to be detected during the "Are you sure you are ready to send this message?" dialog), based on what WADA is noting with the above autosave and confirmation. Again, as noted in my comment 4, only seeming to appear on an SMP machine (Windows, not tested on Linux), and "never" on a uniprocessor machine. WADA, is this something close to what you're reporting? (Sorry about the wordiness and possible off-topic nature; chronic sleep deprivation... go figure...)
(In reply to comment #11) > WADA, is this something close to what you're reporting? I reported nothing about this bug. I only tried to help problem analysis. Please note that I never experienced this bug and never tried to re-create this bug. But I could re-create zombie compose window by your advice. 0. MS Win-XP SP2 on Core2 Duo. Thunderbird trunk(2007/7/17 build) 1. Dummy POP3 account(local Drafts folder) Auto-Save=On(every one minute), Confirmation Dialog(*after* save)=On 2. Compose a mail with 20MB attachment 3 [review]. Save as Draft (took around 1 minute in my test) 4. Edit Draft 5. Ctrl+Shift+Enter (Send Later) => Dialog to send 6. Wait for start of auto-save (by watching Task Manager) 7. When CPU utilization increases, click OK of dialog to send => Dialog *after* auto-save was NOT displayed (indicates canceled) => Mail was successfully saved in Unsent folder => Draft mail was deleted from Drafts folder => Zombie compose window was produced Note: As you say, File menu didn't respond while auto-save was in progress. So "Send Later" from menu while auto-saving was impossible. I think this is not multi-cpu only problem. Even on single-cpu, if interruptions occur in several tasks which relate to this bug, and if scheduling sequence of instructions of multiple tasks become similar one on multi-cpu, problem may occur. However, I believe probability of problem on single-cpu is very much lower (but at least greater than 1/Infinity) than probability on multi-cpu.
Confirming, and adding "auto-save" in bug summary for ease of search.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Compose Window does not close after message has been send → Compose Window does not close after message has been sent (mail send while auto-save is in progress)
Version: 2.0 → Trunk
To konstantinos(bug opener): Do you send mail thru "Ctrl+Enter"? Or "Send button" or File menu? If "Ctrl+Enter", will send thru "Send button" reduce frequency of problem?
I experienced this same problem. It only appears to happen when I try to send a message with an attachment. The attachments I sent were ".zip" files of approx. 20MB in size. Each time I could only get rid of the "Ghost Compose Window" by exiting TB or by just clicking the compose mail button again and it would return to normal within the old "Ghost". Using ver. 2.0.0.6 on Windows XP SP2 and have never noticed this problem before.
I have the same problem with my Thunderbird (2.0.0.6) under Windows XP, already for many moths (maybe 2 years?). Neither checking/unchecking of the auto-save options (or the confirmation) changed the behaviour of the window nor _not_ changing the window to the main Thunderbird window (or any other Thunderbird window) helps. This phantom window is just always there, after I send an e-mail. If I have more drafts opened, and send them one by one, there still remains only one phantom-window, the other disappear. I've checked the same Thunderbird, with the same e-mail-account, but in a new profile and the problem wasn't there, so I think it must be something with my preferences. I was wondering, if it has something in common with my ceritificate (digital signing), which I use while sending all my e-mails (I had a similar problem with Apple Mail under Mac OS), but I didn't test it yet.
(In reply to comment #18) > Neither checking/unchecking of the auto-save options changed the behaviour To Joanna Ludmiła Ryćko: See Dependency tree for for Bug 347693 which is sent in "Depends on:" field of this bug. There are at least 4 bug reports for same "zombie compose window" when defferent situation.
Same problem here, on Windows XP x64 and Vista Ultimate (not 64 bit!) No add-ons installed, no hardware acceleration.
A little more info: under BeOS, the phantom window is present after the *first* message I send. I am able to close the window using the OS "close window" box on the frame. More interesting: if I send other emails after the first one, the window closes on its own.
(In reply to comment #21) > A little more info: under BeOS, the phantom window is present after the > *first* message I send. I am able to close the window using the OS "close > window" box on the frame. More interesting: if I send other emails after the > first one, the window closes on its own. I can confirm this behaviour. In fact, it's always the LAST window, which won't close. The zombie-window changes always to the window of the message, which last was being edited and sent. I also noticed, that sometimes the window actually closes, if I don't change the focus to other windows (see my comment above, where I said, I can't see any dependencies). But these are not only windows in Thunderbird, but also others. (If I don't change the focus in Thunderbird, it's not enought to close this phanotm-window).
Assignee: mscott → nobody
I organise email for a small organisation of half a dozen TB users, running TB 2.0.0.x on Windows XP. We see this problem with some accounts, whereas others (including mine) never get it. We are using POP3 accounts. The distinguishing feature seems to be those who have large 'Sent' folders. My boss was getting this message several times a day. I discovered his 'Sent' folder was > 1GB in size. Another colleague who saw this problem was running his TB account from our SMB server, so although his 'Sent' folder was smaller at 0.6GB, I suspect the extra unreliability in the network meant he was more likely to see it. I had both these users empty their Sent folders and compact them. The problem seems to have disappeared, so I would invite folks suffering from this bug to try it as a work-around. I speculate that this problem is caused by the interaction of, say, an on-demand virus checker and the writing out of the 'Sent' message. Thunderbird throws during the writing of the message - slowed down by large Sent folders - and so fails to close the composition window, which becomes a zombie.
Cause is possibly "auto-save while mail sending even after send request"(Bug 413165) instead of "mail send while auto-save is in progress". Setting dependency to Bug 413165 for ease of tracking.
Depends on: 413165
Comment to deleted bug report 556460: The same problem occurs after the last update of Thunderbird to version 3.0.4, with the last version I had not this problem.
I initially had the issue and was following [Bug 395520]. However, no longer an issue since upgrade to Thunderbird/3.0.5.
This bug is affecting our organisation also. It has been present since 2.0.0.24 ish but may have been present in all versions and only got worse as the size of the sent folder has increased over time. We have no sent items retention policy. Our configuration is IMAP users with mail stores on a RAID NAS drive. Only the minimal amount of mail is stored as IMAP, the majority is stored in Local Folders on the RAID NAS (Including Sent Items) The "Write:" window is up for an extended time showing 100% when sending an email with a moderate size attachment. If you switch away from the "Write:" window when it is at 100% and it does not close itself then the remains of the window will remain. This is pretty adequately described above by others. I had 3808 items (1.5GB) in my Sent folder and the problem occurred every time. I moved all the items to another folder "__Sent" and the problem doesn't occur because the window now doesn't hang around at 100%. Steps to Reproduce: Put a lot of mail in sent. (3500 + items 1.3GB+ Size) Profile / Mail stored on a Network Drive. Write a mail with a 20MB attachment. Hit "Send" and wait for Send to get to 100%. Switch away back to Main Mail window. Hey presto!
Does anyone still see this problem? I don't think we see it mentioned in support forums.
Whiteboard: [closeme 2012-02-21]
(In reply to Wayne Mery (:wsmwk) from comment #32) > Does anyone still see this problem? > > I don't think we see it mentioned in support forums. Have not seen this problem after upgrade to Thunderbird v3.0.5. Now on v10.0.
RESOLVED WORKSFORME per comment 33.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
I am using a newer version of TB (13.0.1) and I have this problem. It seems to have come up since the last update. I am using WinXP and FF 14.0 Real pain to have to close after sending.
(In reply to Tim from comment #35) > I am using a newer version of TB (13.0.1) and I have this problem. It seems > to have come up since the last update. > I am using WinXP and FF 14.0 > Real pain to have to close after sending. Tim, you might check bugs such as bug 413165 and bug 696580. Because the originators of this bug no longer seen the problem
I am using TB 38.2.0 and this problem keeps occurring. I can only get the spent compose window to close if I restart TB. It's fairly recent, perhaps only a few months? So it's NOT resolved
This problem persists in 45.7.1, and started a few months ago on earlier 45.x versions. Running Win10 x64 Enterprise. The only way to close the "orphaned" window is to restart Thunderbird. The window always shows the last message sent. It cannot be minimized, moved, closed, or even receive focus. Thunderbird itself operates properly, and sending a new message will remove the orphaned window, replacing it with a new orphaned window containing the most-recently-sent message. Message are sent properly, and are copied to the "Sent" folder.
(In reply to Joshua Cranmer [:jcranmer] from comment #34) > RESOLVED WORKSFORME per comment 33. This problem still keeps recurring, even on up-to-date Win10 and TB.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: