554305 - detaching attachment downloads message twice

Status: RESOLVED DUPLICATE of bug 373040

(MailNews Core :: Networking: IMAP, defect)

Description

[Phil Lacy]

With view attachments inline cleared (fetch by parts)
select message with attachment. Detach. File and/or message is downloaded twice.
I noticed this with a recent 12meg file. I suspect using this feature is aimed at large attachments like this so it ought to be more network-economical then that.

This may happen for other conditions like open attachment but haven't tried. 

Don't have a log yet. But maybe someone can recognize a fix for this bug.

Comment 1

[rsx11m]

If the problem disappears when setting *both* browser.cache.disk.enable and browser.cache.memory.enable to "false" (and restart Thunderbird), then it's probably the same issue that also causes bug 529210 (uncompleted caching of
MIME parts when downloaded on demand).

You didn't say it explicitly, but I assume that offline synchronization is switched off.

Comment 2

[rsx11m]

Ok, wrong thinking. If you disable the cache completely, the attachment will
have to be reloaded for sure. Disabling MIME parts on demand, i.e., setting mail.server.default.mime_parts_on_demand to false, would be another test.

Comment 3

[WADA:World Anti-bad-Duping Agency]

"Duplicated fetch of an attachmnt part upon open of attachment" was observed in fix verification test of bug 516211(closed as dup of bug 246415 you fixed)  using test mail of Bug 501253. See bug 516211 commnt #13 and IMAP log attached to bug 516211 commnt #14, please.

Comment 4

[WADA:World Anti-bad-Duping Agency]

Failed to likify by mistype.
> See bug 516211 comment #13 and IMAP log attached to bug 516211 comment #14, please.

Comment 5

[Phil Lacy]

synchronization is off. I don't see why that should require downloading twice.

we should be fetching mime headers and then only fetch the part when we say open or detach or save.

Is this a dupe or will this be the bug referenced in bug 516211 comment 15?

Comment 6

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #5)
> synchronization is off. I don't see why that should require downloading twice.

For first download.
It's probably simply because of current design/implementation of Disk(and Memory) Cache. See bug 565852 comment #26(and #27).

For second download.
I couldn't see it in bug 516211. See bug 516211 comment #16. Can you see second download attempt after fix of bug 565852?

Comment 7

[Wayne Mery (:wsmwk)]

(In reply to comment #6)
> For second download.
> I couldn't see it in bug 516211. See bug 516211 comment #16. Can you see second
> download attempt after fix of bug 565852?

Phil, bug 565852 is fixed. Can you still reproduce your issue with TB 3.1.8pre/3.1.9pre or 3.1.8?
ftp://ftp.mozilla.org/pub/thunderbird/nightly/latest-comm-1.9.2/

Comment 8

[rsx11m]

> I noticed this with a recent 12meg file.

Keep in mind that the memory cache only has a default size of 4MB (bug 629247), thus unless you have the disk cache enabled, all attachments larger than that size will be re-downloaded if accessed for a second time (this includes delete and detach of attachments, given that the message is actually duplicated and rewritten without the attachment).

Comment 9

[rsx11m]

Observations with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.14) Gecko/20110123 Thunderbird/3.1.8, using a single-attachment multipart/mixed message which fits into the memory cache, no offline synchronization:

(A) mail.server.default.mime_parts_on_demand = false:

1. Message opens, downloads in full (1st download)

2a. Without opening attachment, detach it, no 2nd download
3a. Confirm deletion of original attachment on server
4a. Message without attachment written back, no 2nd download

2b. Open attachment after step #1, no 2nd download
3b. Chose detach and confirm dialog
4b. Message without attachment written back, no 2nd download

(B) mail.server.default.mime_parts_on_demand = true:

1. Message opens, only text part is loaded, then stops

2a. Without opening attachment, detach it
3a. Attachment is now loaded and saved (1st download, expected)
4a. Confirm deletion of original attachment on server
5a. Attachment or message is downloaded again (2nd download, this bug)
6a. Message without attachment written back after 2nd download

2b. Opening attachment, loaded, then application dialog (1st download)
3b. Attachment is re-cached in the background (2nd time, bug 629738)
4b. Pick application, then close it after the document has been shown
5b. Detach the attachment, this time the cached version is saved (desired)
6b. Confirm deletion of original attachment on server
7b. Attachment or message is downloaded again (3rd download, this bug)
8b. Message without attachment written back after 3rd download

Thus, the attachment is now downloaded up to three times if MIME parts on demand is enabled. The first redundant download (B.3b) can be attributed to
bug 629738 whereas the second redundant download (B.5a, B.7b) implies that
this bug is still present in TB 3.1.8 even after bug 565852 landing. This is also independent of bug 629738 given that the message-list view only updates after the last download is completed, thus cannot be explained with refreshing the cache in the background (which is subject of bug 629738).

Comment 10

[Wayne Mery (:wsmwk)]

duplicate of bug 373040?