362491 - Drag-and-drop attachments fail upon saving

Status: RESOLVED INCOMPLETE

(Thunderbird :: Message Compose Window, defect)

Description

[Keith Hanlan]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Build Identifier: Thunderbird/1.5.0.8

A colleague reported this problem and I've been able to reproduce it. If we  add an attachment using drag-and-drop from the KDE desktop, the GUI updates appropriately showing the filename. However, when we go to save or send the email, it hangs while attaching. In /tmp, a temporary file (called nsmail-N.tmp) is created but it remains at zero bytes. There are no permissions problems on the file.

The "Attaching..." popup appears and the progress meter simply loops around indefinitely.

Reproducible: Always

Steps to Reproduce:
1. compose 
2. drag and drop a file (big or small, doesn't matter) from konqueror into the attachment pane
3. click save

Actual Results:  
The "Attaching..." popup appears and the progress meter simply loops around indefinitely.

Expected Results:  
The mail should be saved

Comment 1

[Magnus Melin [:mkmelin]]

WFM on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.1pre) Gecko/20061129 Thunderbird/2.0b1pre ID:2006112903

Comment 2

[Keith Hanlan]

I'll re-try it with the 2.0 version when I get back into the office on Monday.

The problem was seen on two identical RHEL-4 systems: my client was talking to a courier-imap server and my colleage's client to an Exchange 2005 server through its IMAP interface. (Although, the problem seems to happen while it is constructing the message so imap probably doesn't factor in to it.) 

It works for me at home on FC6.

There were no disk quota problems.

Comment 3

[Thomas D. (:thomas8)]

This bug also occurs in Windows XP / TB version 2.0.0.0 (20070326) en.Us
It is interesting (and wrong) that there seem to be two different procedures within TB depending on the way in which the attachment is added. Compare these scenarios:

Scenario 1) - attach via Explorer context menu > Send to

Steps:
- select several files in Windows Explorer, context menu, Send to > email recipient
Actual Result (as expected):
- files are attached in gui, and a temporary copy of the file is saved in temp/moz_mapi folder
In other words, mozilla will just use its temporary copy of the original file in the state of the point of time of attaching (saved snapshot of the file). Therefore, later changes of the original file will not be reflected in the attachment. I can even delete the original file, as mozilla will just use the tmp snapshot copy from the moz_mapi folder.

Scenario 2 (this bug) - attach via drag&drop

Steps to reproduce:
1. drag & drop an additional file from windows explorer into mail composition attachment pane.
2. attachment shows fine in the gui
3. delete the original file (because you expect a temp snapshot copy of the file must be in temp/moz_mapi, just as described above)
4. try to save or send message

Actual results:
- data loss: I expected TB to have created a snapshot temp-copy of my file, but there is none, and I deleted my original file in good faith!
- saving/sending fails with the following error msg:
"Unable to save your msg as draft. Unable to open the temporary file F:\DCIM\Fotos\test4.jpg. Check your 'Temporary Directory' Setting."
However, the location given in the error msg is simply the location of the ORIGINAL file, not the temporary directory temp/moz_mapi as expected. In my case, F: is an external USB device / sd card reader (don't know if that plays a role). So the error msg is wrong, because there are no problems with my temporary directory setting as can be seen from Scenario 1 above.
NB: Where do I check 'Temporary Directory' setting anyway?
- danger of wrong data being sent: if I modify the file AFTER having attached it, TB will send the NEW version, but according to Scenario 1, I expected it to send a snapshot of the original version!

Expected results:
- As soon as I attach a file via drag & drop, a snapshot copy of that file should be created in the temporary directory temp/moz_mapi, just like in Scenario 1 above. So even if I decide to change/delete original file before saving/sending my mail, the attachment snapshot copy in temp/moz_mapi folder will still be there and can be saved/sent with the email without any probs.

Ideas for fixing this bug: I don't understand why there are obviously two different procedures in the code, because as soon as attachment file names are known, the procedure of saving temporary file should use the same code (no matter if file name has been passed via explorer's SendTo or Drag&drop).

I suggest the following changes to this bug:
- Status: NEW
- OS: linux+windows (probably all...)
- Severity: normal (danger of data loss, danger of wrong version of attachment file being send without notice)

Comment 4

[Davis Scott]

I find a similar problem. Thunderbird 2.0.0.17 (and earlier) frequently locks up when dragging an attachment from an incoming email to an outgoing composition. The only way out is ctrl-alt-dele. The workaround is to save the incoming attachment to another location, i.e. my docs or desktop, and then copy it to the outgoing message. OS is XP Pro SP 2.

Comment 5

[Wayne Mery (:wsmwk)]

does this reproduce in v3?