User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 this is probably related to bug 240307, but involves large text emails, not attachments, so the workaround offered there doesn't work. basically, trying to reply to an email larger than 650K causes thunderbird to go to high cpu utilization, and stay there. only thing i can do is to 'kill -9' it and start it again. i've found no way to reply to such mails. i'd also love an option to automatically snip out parts of the original mail body when quoting it in the reply (e.g. show first 20 lines, last 20 lines, 10 first and 10 last etc.) Reproducible: Always Steps to Reproduce: 1.send yourself an email with 650K body 2.try to reply to the mail 3. Actual Results: thunderbird hangs in 100% cpu utilization Expected Results: allow me to compose a reply
I see the same behaviour as original poster using Thunderbird 1.0.6 20050716. (I'm pretty sure it happens in 1.5 beta as well.) However it's not a complete hang, my Pentium 4 Windows 2000 machine eventually comes back to life after a period of about 30 seconds of 100% CPU utilisation. The same problem happens when you try to Forward a message with 1mb of text, or even if you open a completely new message, and paste about 1MB of plain text from the clipboard. Further testing reveals that this may be due to the conversion between plain text and HTML. If I uncheck the "Tools, Account Settings, Composition & Addressing, Compose Message in HTML format" checkbox, then the wait is drastically reduced. Also, if you go through the original poster's "steps to reproduce" but compose a HTML message, the delay after replying to yourself is much more reasonable.
yup, confirming, that conversion goes through some painfully inefficient code.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: large text emails cause thunderbird to hand on reply → large text emails cause thunderbird to hang on reply
David, OS=ALL? related to bug 240307? ittayd, does your testing match/agree with comment 2? And is the problem reduced with version 1.5 or trunk?
i'm using TB 1.5 i sent an email to myself with an attached 1.2MB ascii log file i tried to reply to myself, making sure the HTML conversion option is off TB took about 3 minutes to reply, and put the log file's contents inline (part of the email's text), which is bad in itself, since it means the imaginary recepient cannot (easily) save it. i think it should take less to reply to such a message, and that attachments that are too big should never be made part of the email's body (keep as attachments when forwarding, drop when replying). i don't think anyone really wants to comment on a 1.2MB text.
seems like a combination of the two. reply shouldn't quote inline attachments if they are too big (for small ones, this is actually very useful, but once an attachment is big, there's no point in quoting it). after that, maybe it's the speller's performance which is to blame. i don't know. however, i also thing that spelling huge documents is not needed. i don't think people type in huge emails (how much is 'huge' should be defined of course). if the email is huge, it means probably some copy&paste. if the copy&paste is from a log file, the speller will probably have a lot of work (encountering accronyms and such)
So did turning off inline spell checking help? If so, mark this as duplicate of bug 324521. (BTW, bug 358124 will make us stop quoting text attachments.)
it didn't solve the issue, looks like the time it takes to reply is pretty much the same
WRT your comment 7, if you want to only quote part of the original you need to file a new bug - thunderbird isn't going to "intelligently" or otherwise decide to stop quoting a certain poitn. bug 289644 is also about plaintext
I see the issue with a plain text email, 1.3MB, which is a build log. I have to reply to it and comment on parts of it, and because of it's regular structure, doing so is easy. Thanks, by the way, for the find dialog. So, these are the numbers: (on a dual core machine, both cores constantly busy, though not at 100%) - 45sec opening the reply window - 45sec closing it again - 45sec opening the reply window - 180sec remove the not-required portions (from line 10 to line $-10) Turing off the immediate spell checker reduces the open-window time from 45sec to 38sec. So that does not seem to be the major influence here. Local folders. No IMAP, no HTML, no attachments in the pircure. Thanks for all your effort!
Component: Mail Window Front End → Message Compose Window
QA Contact: front-end → message-compose
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 289644
You need to log in before you can comment on or make changes to this bug.