1.33 MB, application/x-compressed
49.20 KB, application/octet-stream
675.87 KB, text/html
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/188.8.131.524 Safari/532.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206) Loading of mail with a large attachment hangs. The progress bar keeps increasing, but Thunderbird is nearly completely unresponsive. If you wait long enough it might succeed in loading the message instead of hanging. The only solution is to hide the preview pane (F8) and delete the message. This happens with the following emails: 1. A email sent by my server from a cron job with a large body. 2. I send an email with an attachment but it bounces back. The bounced email is impossible to read. Reproducible: Always Steps to Reproduce: 1. Send an email with an attachment between 5Mb - 13Mb; make sure it will bounce. 2. When the bounce arrives, click it to load in the preview pane. 3. Wait forever.... Actual Results: See description. Expected Results: The message [body] should load in the preview pane, and any attachments to be listed as attachments separately (as it normally does).
Can you provide a test message that exhibits the issue ?
Sure, how do you want me to give you the message? Should I save the message as file, eml, or what?
try http://www.payserv.ro/failurenotice.eml it's 10.7Mb in size.
It's slow for me when loading localy - so I imagine that with pop or imap overhead it doesn't help. However It's doesn't hand with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:220.127.116.11pre) Gecko/20100427 Thunderbird/3.1b2
I am using POP3S but I shouldn't imagine that makes a difference, does it? The message has already been downloaded, it's just a question of loading it into the preview pane, right? Also, don't forget on my box when the slow loading happens, the UI is almost completely unusable.
Adding qawanted so someone can profile where we are spending time and why this is so slow. Gary how would you feel about sharking this ?
Status: UNCONFIRMED → NEW
Ever confirmed: true
This bug feels amazingly deja vu-ish - smells like a known Core issue but I just can't think of the bug number now. Wayne / Standard8 - do you guys recall?
I think I have found the same bug, downloading larger files with POP3 takes a looong time, and seems to send/receive a lot more network traffic than what should be necessary. I created a small 1MB test file from /dev/urandom, see the attached log for debugging output.
Created attachment 452274 [details] Log file for this problem, for TB 3.0.5 Maybe I should add that this happened for TB 3.0.5 (and earlier versions) here.
(In reply to comment #9) > I think I have found the same bug, downloading larger files with POP3 takes a > looong time, and seems to send/receive a lot more network traffic than what > should be necessary. I created a small 1MB test file from /dev/urandom, see > the attached log for debugging output. rubikcube from irc? note, this bug is about VIEWING taking a long time. you probably want to be looking for a bug in product Mailnews+Core component Networking: POP
(In reply to comment #7) > This bug feels amazingly deja vu-ish - smells like a known Core issue but I > just can't think of the bug number now. > > Wayne / Standard8 - do you guys recall? yes, and no. Fridays a bad day for me to remember bug#/names. :) However, there is >1 core bug - what it matches up to depends on the message contents. A starting query http://bit.ly/bBkzBA - which an be more focused by either a limiting to major or adding "has comments or cc from "bz"" (because he is involved with many of these types of core bugs. (In reply to comment #8) > See also bug 337393 though I'm not sure if they're the same issue. depends on the contents of the example message from the reporter
(In reply to comment #11) > rubikcube from irc? note, this bug is about VIEWING taking a long time. you > probably want to be looking for a bug in > product Mailnews+Core > component Networking: POP You were probably right, it's bug #573432 now. Thanks for the advice.
I have seen what I think is the same problem, but I don;t think it is related to the downloading, rather the preparation to render a plain text attachment in the preview pane. My attachment is a plain text file of 6.3Mb. Clicking on it (with preview pane)locks me out with slowly filling progress bar. Eventually it does open though. Perhaps a file size check on preview could be added to block large attachments being opened it full? I am using 3.1.4 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168) Gecko/20090302 Lightning/0.9 Thunderbird/22.214.171.124 Mnenhy/0.7.6.0)
I've run into this issue recently. Someone sent me 20 MB plain text file as an attachment (yes, he should have zipped it, but that's beside the point), and when I click to view it with the preview pane open, Thunderbird hangs for quite a while--slower, I imagine, if I were on a slower internet connection. I agree that Thunderbird should handle this situation more gracefully, at least preventing the loading of the large text file in the preview. It could give the user the option of loading the file into the preview, but that's not the most useful thing when it will cause the application to hang. I think this issue could come up with other large, preview-able file types (images, for instance), so it shouldn't be limited to TXT files. Mozilla/5.0 (Windows NT 5.1; rv:2.0b12pre) Gecko/20110209 Thunderbird/3.3a3pre
Yes, same here, it is very annoying, I need to have attachment preview disabled all the time, because I'm getting xml and csv files by email quite often. Thunderbird simply hangs when you try to try to view the email with plain text attachment (such as xml in my exapmle). One CPU core is burning at 100% and nothing happens for several minutes, depending on the size. It does not have to be large, I tried with xml of about 500kb and it takes more than 5 minutes (!!!) to load. I have uploaded the zipped 50kB example here: http://stopar.borec.cz/thunderbird-hang-test.zip
Created attachment 539732 [details] Try to open vith attachment preview enabled and it will hang thunderbird for long minutes.
Created attachment 8701867 [details] Get Started with Dropbox.pdf I want to loading this site
Would it make sense to simply add a sanity check on the size of attachments that are displayed inline? If you have a 10 MB text file, you're probably not going to read all of it in Thunderbird anyway. We could just render the first 100 KB and then, if it's larger, add a little note that says "open the attachment in an external editor to see the rest". That said, it'd be worth figuring out if we can make this a bit faster anyway.
You need to log in before you can comment on or make changes to this bug.