556591 - Sending an email with multiple attachments (forward as attachment) does not close the compose window on completion of send process

Status: RESOLVED DUPLICATE of bug 380275

(Thunderbird :: Message Compose Window, defect)

Description

[Shiner]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.2) Gecko/20100316 Firefox/3.6.2 GTB6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4

Using Thunderbird 3.x.x I've noticed a problem when sending an email with a large number of attachments (specifically forwarded emails) in that on completion of sending, the email compose window remains on the task bar. You cannot select the 'composed email', nor close it. (i.e. you cannot give it focus).
The only way to remove the 'compose email window' is to close Thunderbird down, or a much quicker method is to send a new email.

Upon sending a new email, instead of creating a compose window on the task bar, it 'reuses' the old 'compose email' (object). Providing this is a short email, upon sending, it is cleared from the task bar.

All the other operations associated with sending a mail function ok (i.e. it is copied to the sent folder, it is delivered ok, etc etc). The problem is simply with removing the reference to the object that was the old compose window

It is repeatable, and as of yet, I haven't managed to determine what size, or what number of attachments will cause it exactly.

The problem arose because I submit my spam to a Spamcop reporting address which involves sending a single mail with multiple spam emails as attachments.
To recreate the problem, you can do the following: 

Reproducible: Always

Steps to Reproduce:
1.Highlight a large list of emails (>100 always recreates the problem)
2. Right click and select, "Forward as Attachments"
3. A new mail is created
4. Set a From: address (if multiple accounts exist in your profile)
5. Set a To: address (it breaks if any To: address is used)
6. Click send. 

In this instance, the account used was a POP account (i.e. I haven't tried it using an IMAP account).

To get rid of the menu, all you need to do is open a new compose window (from the menu or control N). It doesn't open a new compose window, but brings the 'old' one back into focus and uses that window.  Providing the email doesn't have too many attachments, when you press send, on completion the compose window closes as expected.
Actual Results:  
Upon sending the email, the completed compose windowis not removed from the task bar.

You cannot select the compose window object from the task bar (it has no right click, minimise, maximise close options etc). Clicking on the old compose window does not give focus to the main Thunderbird client.



Expected Results:  
On completion of sending an email, the old compose window should close.

I've reproduced the same problem on a Win7 machine with a stock install of both the OS and Thunderbid (no additional addons)

I will have a go at repeating it on my Fedora box if I get the time.

Comment 1

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #0)
> I've noticed a problem when sending an email with a large number of attachments 
> Upon sending a new email, instead of creating a compose window on the task bar,
> it 'reuses' the old 'compose email' (object).

Sounds same issue as bug 380275. See dependency tree for Bug 347693(with "Show Resolved") for similar issues.
Do you enable auto-save? With what interval? Do you enable dialog after save(checl box in Copies&Folders)? 
	

:

Comment 2

[Shiner]

First off, apologies... Somehow I missed the previous bug and I assure you I did search.

It does sound similar.

I do have Auto Save set, and with a 5min interval.
I don't have the enable dialog enabled on any of the accounts that show this problem.

It does sound if 'some process still has a handle to the open compose window when the mail has been sent, which prevents that object from being deleted. 
Since it is related to the 'size' of the email, there is probably some sort of race condition preventing the deletion of the completed compose window.

380275 was an old bug, was it ever fixed?
It didn't appear so from the report.

I'll let someone of higher authority determine whether to mark this bug report as a duplicate and to add a comment to 380275