974425 - Attached file is truncated if select another one while downloading a message and fetch_by_chunks is true

Status: UNCONFIRMED

(MailNews Core :: Networking: IMAP, defect)

Description

[kkamada]

User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 (Beta/Release)
Build ID: 20140212131424

Steps to reproduce:

1. Use an IMAP account.
2. Send a message attached a large file (ex. 30MB), and Thunderbird receives it automatically.
3. Thunderbird receives that message and shows it as unread in the message list.
4. Select that message in the message list, and click "Forward" button in the message preview pane.
5. Select another message in the message list while the status bar shows as "Downloading message".


Actual results:

Thunderbird cancels the message downloading.
And shows the message compose window for creating a forward message, but attached file size is less than an original.


Expected results:

Thunderbird downloads the message completely.
And shows the message compose window for creating a forward message, and attached file size is equal to an original.

Comment 1

[kkamada]

I know a workaround the value of the "mail.server.default.fetch_by_chunks" configuration is set to "false".
But I think it is not an underlying solution.

Comment 2

[Wayne Mery (:wsmwk)]

Gene, have you come across this in other bugs?

Comment 3

[gene smith]

No, I've never tried doing that. I will give it a try and leave NI on. (Have noticed that chunking causes more problems than it actually solves, and never could find exactly what it is intended to solve!)

Comment 4

[gene smith]

I tried this with a large attachment and it seemed to work OK. I think maybe this is no longer an issue due to changes Jorg made to caching to memory in v52. However, not sure if the reporter is using memory cache or default offline storage cache when the problem was originally seen. Will do some more testing tomorrow so still leaving NI set.

Comment 5

[gene smith]

I still don't see a problem with only memory cache or with full offline storage sync. I tested with a large 15M attachment. I also reduced the browser.cache.memory.max_entry_size from default 25000 (25M) down to 12000 (12M) and don't see a difference (this should compensate for the smaller attachment I am testing with, 15M vs. the 30M attachment the reporter used).

I noticed that the chunking kept occurring after "forward" clicked and while the other small message was displayed and it took about 30-40 seconds to complete before the forwarded email write window came up with the correct attachments sizes shown. The progress bar at the bottom right gave an indication that something was going on in the background.