373040 - Detaching attachments downloads message twice

Status: NEW

(Thunderbird :: Message Reader UI, defect)

Description

[Doug Speckhard]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2
Build Identifier: version 2.0pre (20070306)

When using the "Detach" feature, the attachments are downloaded (to save the file), then the whole message (with attachments) is downloaded again, then (I assume) the local copy of the message body is fixed to refer to the local copy of the attachment and saved as a new message, then the original message is deleted. This means that the user has to wait for the attachments to download twice, which can be cumbersome for large (slow) attachments.

Reproducible: Always

Steps to Reproduce:
1. Right click on an attachment in the lower portion of the message window
2. Navigate the "Save All Attachments" dialog to where the attachment should live (name of this dialog is wrong)
3. Wait while attachment downloads
4. Prompt appears "Confirm: The following attachments have been successfully saved and will now be permanently deleted from this message: <filename> This action cannot be undone. Do you wish to Continue?" - select OK
5. Wait while the message re-downloads
6. Finally, the message is re-saved without the attached file. 
Actual Results:  
User has to wait (step 5)

Expected Results:  
Message is immediately re-saved, based on cached local copy.

Comment 1

[David :Bienvenu]

yeah, unfortunately, they are truly different messages, and our caching system is based on the identity of the message, in the imap case, the uid of the message. The original message and the detached message have two different uids. And the messages themselves are actually different. So this is very hard to fix with our current caching system.

I'd suggest hiding the message pane with F8 if you know this is going to be a problem.

Comment 2

[Doug Speckhard]

I understand why the new message needs to be re-downloaded (and cached)but since we're creating the new message, why do we need to download the copy with the attachment again?

Comment 3

[Anthony DiSante]

I can confirm this behavior.  For maximum frustrating effect, you should receive a few emails each week with 20MB+ attachments, on email servers with slow connections, so that for each message, you waste not 20 minutes, but 40 minutes.

And as Doug's second question implies, David's explanation doesn't really make sense.  The second message would no longer contain the attachment, so it should take just a few seconds to download; TB should not re-download the entire huge (previously-detached) attachment again.

Also, should this be assigned somewhere other than "Mail Window Front End"?

Comment 4

[Gonz Hauser]

I can confirm this.
Attachments should be cached locally. It's annoying to see Thunderbird download the same attachment again and again.

For example:
1. Receive a new message with a big attachment: Download number 1.
2. Close Thunderbird, open again: Download number 2.
3. Forward message, download number 3, upload number 1, and save to "sent folder", download 4 and upload 2.
4. Accidently click on the message: Download number 5

It _really_ should be possible to cache the attachment, otherwise it is not possible to use Thunderbird when working with big attachments.

Comment 6

[Wayne Mery (:wsmwk)]

do you see this problem with version 3?

Comment 8

[sphakka]

I believe there's a somewhat deeper issue with the caching system, as I'm seeing *every* msg (from a GMail IMAP account) re-downloaded every time I click on it in the msg pane.

Comment 9

[Wayne Mery (:wsmwk)]

(In reply to sphakka from comment #8)
> I believe there's a somewhat deeper issue with the caching system, as I'm
> seeing *every* msg (from a GMail IMAP account) re-downloaded every time I
> click on it in the msg pane.

Your issue is not this bug unless you are doing detaches.   If you are using imap, perhaps one of these https://mzl.la/2Dp8KbH

Comment 10

[sphakka]

Thanks for the info, Wayne. Indeed you're correct: I guess mine was a problem with an old SeaMonkey, fixed after updating to SM-2.49.5.2 :-) 

I confirm the issue with detaching in SeaMonkey Mail. AFAIK the code base is the same, or should I open a SM-specific bug?