365419 - Composition very slow when forwarding mail containing HTML/XML

Status: RESOLVED DUPLICATE of bug 324521

(Thunderbird :: Message Compose Window, defect)

Description

[Richard Dawe]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.0.9) Gecko/20061219 Fedora/1.5.0.9-1.fc6 Firefox/1.5.0.9 pango-text
Build Identifier: version 1.5.0.9 (20061219)

When I try forwarding inline a mail containing HTML or XML, it can take several tens of seconds to finish drawing the mail composition window. It doesn't do it for every mail containing HTML or XML, but more often than not it does.

Forwarding attached does not seem to suffer from this problem.

Reproducible: Always

Steps to Reproduce:
1. Send yourself the attached mail (using SMTP rather than, say, Thunderbird).
2. Try forwarding the mail inline.
3. Try forwarding the mail attached instead.

Comment 1

[Richard Dawe]

Attachment: A recent example mail from this problem

Here is the mail sample that I've been testing with today. I hit this bug every time I try to forward this sample inline. If I forward it attached, there is no problem.

Comment 2

[Richard Dawe]

I've tested with the following environment variables:

export NSPR_LOG_MODULES=all:5
export NSPR_LOG_FILE=/var/tmp/thunderbird-20061230.log

From my testing it seems that the composer is slow when it's doing the following kind of operations:

...
-1209112352[9d3b548]: -- nsOSHelperAppService::ExternalProtocolHandlerExists for
 'xmlns'
-1209112352[9d3b548]: -- nsOSHelperAppService::ExternalProtocolHandlerExists for
 'Build'
-1209112352[9d3b548]: -- nsOSHelperAppService::ExternalProtocolHandlerExists for
 'C'
-1209112352[9d3b548]: -- nsOSHelperAppService::ExternalProtocolHandlerExists for
 'C'
-1209112352[9d3b548]: -- nsOSHelperAppService::ExternalProtocolHandlerExists for
 'systeminfo'
...

I was tailing the log file, and there were reasonably long pauses (~10-100 ms) between each of those log entries. I'm running on an old box -- an Athlon 850MHz with plenty of RAM and disk.

Here is a comparison of the calls to nsOSHelperAppService::ExternalProtocolHandlerExists() for forwarding inline and forwarding attached:

attached: 598 calls (run 1), 462 calls (run 2)
inline: 190

Not sure what the difference is between run 1 and run 2. Perhaps I marked the message as unread before I exited Thunderbird.

From another debugging session a couple of weeks back, I straced thunderbird and noticed that it was waiting a lot on a Unix domain socket that was being used by ORBit2. I guess these may have been CORBA calls into GConf?

I'm wondering if the composer is trying to do something magic with the XML namespace declarations. Is it trying to highlight them in some way?

Perhaps the composer should cache the calls to nsOSHelperAppService::ExternalProtocolHandlerExists() when it's building the copy of the message for inline forwarding?

Comment 3

[Richard Dawe]

I meant also to add a reference to bug 128668 – Use GNOME application associations.

Comment 4

[Mike Cowperthwaite]

Do you see better performance if you turn off inline spellchecking?  There was a much-duped bug fixed (for 2.0) recently -- bug 324521.  If turning off spellchecking fixes the problem for you, please mark this bug as a dupe of that one.

Comment 5

[Richard Dawe]

Yes, that makes an enormous difference when forwarding the mail sample I attached -- thanks!

Sorry I didn't try this before. I did read through all the spellchecking bugs. For some reason I didn't think 1.5.0.x had spellchecking.

I also noticed that it would pause for tens of seconds after I entered a recipient. Perhaps it was spellchecking the message, after tab-completing the recipient?

Comment 6

[Mike Cowperthwaite]

(In reply to comment #5)
> I also noticed that it would pause for tens of seconds after I entered a
> recipient. Perhaps it was spellchecking the message, after tab-completing the
> recipient?

Bug 363113?