Closed Bug 337393 Opened 18 years ago Closed 7 years ago

Slow loading of messages with large attached text files if "Display Attachments Inline" enabled

Categories

(Thunderbird :: Mail Window Front End, defect)

x86
Windows XP
defect
Not set
major

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 736951

People

(Reporter: slowmo, Unassigned)

References

Details

(Keywords: perf, Whiteboard: [needs link to core bug])

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060508 Minefield/3.0a1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060508 Minefield/3.0a1

When trying to view an e-mail which has a large text file (xml in my case, that is > 400KiB in size) attached, this message is loading very long. During that, interface becomes non-responsive with a 100% CPU usage. It takes more than a minute to load such an e-mail on a 3,2Mhz P4.
All that is due to the fact that contents of an attachment is shown at the bottom of a message, if it is an image or a text file.

Reproducible: Always

Steps to Reproduce:
1. Receive an e-mail with a big text file as an attachment (~400Kb)
2. Try to open it.
you can always turn off view | attachments inline
But maybe this could be made so, that loading of attachment runs in a separate thread, that doesn't block the main thread. This way loading could be aborted, when selecting some other e-mail.
QA Contact: front-end
Since there is a workaround (turn off view -> attachments inline), is this better considered an enhancement?
Assignee: mscott → nobody
(In reply to comment #2)
> But maybe this could be made so, that loading of attachment runs in a separate
> thread, that doesn't block the main thread. This way loading could be aborted,
> when selecting some other e-mail.

I think there is a bug where david (or someone else) recently talks about this very idea
(In reply to comment #5)
> (In reply to comment #2)
> > But maybe this could be made so, that loading of attachment runs in a separate
> > thread, that doesn't block the main thread. This way loading could be aborted,
> > when selecting some other e-mail.
> 
> I think there is a bug where david (or someone else) recently talks about this
> very idea

bienvenu do you recall some comment/discussion in this time frame of spring 2008 of making imap less UI blocking? (maybe it was someone else, but seems unlikely)
I'm reasonably sure it doesn't have to do with imap, which operates on a separate thread - the slowdown is probably in parsing/laying out the message, e.g., running it thought the moztxttohtml conversion process.
then it must be about making it so attachment "loading could be aborted, when selecting some other e-mail"
the actual imap part of loading can be interrupted today, though with autosync, you wouldn't often run into it - but the parsing/layout can not be aborted.
What's the version number of the build? If its 2.x and there's lots of remote images/links then it could suffer from a different bug.
(In reply to comment #10)
> What's the version number of the build? If its 2.x and there's lots of remote
> images/links then it could suffer from a different bug.

Hmm, maybe I read the bug wrong, but we should still get a version for this.
Hi, I have version 2.0.0.21 (20090302) - this happens even when there is a single large attachment like a Word document.  Thanks, sriram.
This happens also to me, Thunderbird v..
If I highlight a message which has attached a big file or jpg image, no matter if I've disabled the "view attachments inline" option, the program still pratically hangs but the CPU doesn't rocket up to 100%, but keeps on 1-2%
See bug 447987 comment #21, this might be related to some of the bug(s) listed there, though I'm not sure which.
Keywords: perf
I suggest that TB never shows text files larger than, say, 100 KB inline.
There is a bug on Mac OS X (Snow L.) Display is very long and attachements icon are displayed in front of an another message when changing message during loading of the "long" message. When display inline is choosed. No bug when display inline is not choosed.

Settings for display inline messages should be better... A max size couldn't be added in Advanced Settings ? Dreaming would be by filetype. 

I know it's heavy but i'm a dreamer.
I'm faced with this issue too. Large XML files (like 600k) attached as a text file makes the email preview show after well over a minute.
Even if Thunderbird does not cache the attachment, my IMAP server is local so it's not the time it takes to download the attachment, but the time it takes to render it. I can't help feeling that the rendering code is not very efficient. If I open such an XML in Internet Explorer, it is rendered in a second (including colors and idents). May be the problem is with the automatic word wrap (having to cust the lines to fit the window).

Turning off the preview is not a solution, but an annoyance. The solutions should be either to add a settings to disable showing large texts inline (or automatically trim them), and a better solution is obviously to rewrite the code which renders so slowly...
I'm running TB 3.1.7 on Windows 7 64 bit using an Intel i5 @ 2.8ghz CPU.
I've just noticed the "Display Attachments Inline" option. So turning that option off, solves the issue. I hardly need attachments to be displayed inline, and this option has nothing to do with the option to view the message pane.

BTW... UNICODE text file attachment (for instance, Backup Exec sends its report in UNICODE) is displayed as junk characters when displayed inline. however, this is a different bug.
Whiteboard: [needs link to core bug]
I can confirm the "Display Attachments Inline" option fixes the bug for me.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Slow loading of messages with large attached text files → Slow loading of messages with large attached text files if "Display Attachments Inline" enabled
This also affects large text messages without attachments. Starting from 500k Thunderbird becomes noticeable slow. This was tested on a new 15.0 release in Linux Ubuntu 64 bit with plenty of mem and cpu.
So there are situations where turning of display of attachments does not work.
Somehow my problem is related to the number of Addons activated. Probably the email is processed by every Addon before displayed and for some reasons this process is very slow. 
The Addon produced the most trouble is Enigmail. When almost all Addons are deactivated an email of 1 MB opens within 2 seconds (which is still not fast IMHO). With Enigmal activated it takes up to 30 seconds. With other Addons it goes up to 5 seconds or more.
Note to everyone on the CC list: Please vote for this bug if it's important to you.
I do not have add-ons to TB and theses day i received some large text messages (> 30mo), i know this is weird but anyway thunderbird become very slow, froze while loading the messages. So i can confirm this is not an add-on related problem.
This is bug 736951
Severity: normal → major
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.