Open Bug 1175121 Opened 5 years ago Updated 1 year ago
Large attachments delay message body display
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0 Build ID: 20150525141253 Steps to reproduce: Get someone to send you an email with a large/huge attachment (say 15M or larger). I'm using TB's latest 38.0.1 but this used to happen on older versions as well. Actual results: You won't be able to see the body of the email due to the time it takes to download the attachment. The larger the attachment the longer the time. Expected results: Many times I don't care about the attachment but DO care about the email message body. The email body should be downloaded and displayed immediately sans delay in lieu of waiting for the entire message to download (attachment included) before being able to see the email message body/content. Show me the email message body and even prompt me about attachment download (or show me a status bar or a "download arrow" akin to Firefox's download arrow to note attachment download progress). In passing, I often gets emails with large attachments which I don't care about and so one should be able to delete a message prior to the attachment downloading completely (but maybe that's an entirely different topic and possible a different bug report).
(backdating to TB31)
Component: Untriaged → Message Reader UI
Version: 38 → 31
Does "backdating" to 31 mean that the problem is not there in TB-38.0.1 ?
The above (ie. original problem report) is a serious issue and should be solved/resolved - the below is not meant to muddy-up the waters and is simply meant to note further possible context. On a related topic (and I don't know if a separate bug reported is warranted for this) - here are some observations utilizing Thunderbird-38.0.1 If it so happens that you get a tiny email after getting a large attachment on a previous email which is still "Loading Message..." and is in the process of downloading the large attachment - you won't be able to display the tiny email's contents (body) until the attachment downloads. This very much seems wrong as the attachment holds-off any other "receive" progress from functioning which I don't think is the intended behavior. Gets a bit worse, no email messages are downloaded to TB from the server if this large attachment is being downloaded. So if I get a new email while an attachment is being downloaded, I won't get the new email indicator until the download completes - I won't even _know_ about the new email at all until the attachment is downloaded. Can't there be multiple "pipes" to the server ? So the attachment download would be one thread and other things can continue to occur/happen normally ?
You need to log in before you can comment on or make changes to this bug.