Displaying messages is fairly slow

[RalfJung]

When I click a message, even one that has no other message in its conversation, showing that message takes way longer than it does with the plain Thunderbird view. The latter is instantaneous, while the plugin slows it down to at least a tenth of a seconds until the message is first shown, and then another tenth of a second until it stops re-flowing the auto-reply boxes (they always hop around when switching threads). This is particularly noticeable when scrolling through a folder of a mailing-list, where I'm not really interested in most messages and just go through them by pressing "n" repeatedly. Now I have to actively wait after every "n" to avoid skipping messages.

Once the displayed conversation contains more than a single message, showing it can easily take more than a second (I'd estimate that happens around 5 messages/thread). With 10 messages, it's already 2-3 seconds.

[protz]

Right, so there's two issues here that come into play.

• The first one is the super-infamous bug 80713. Several people (including myself) have failed at fixing it. Basically, 1) messages need to be displayed in an iframe so that they are in a different security principal than the rest of the UI 2) HTML5 has a way to say "this iframe should behave like a div and take as much height as needed" but 3) this is not implemented (bug 80713). Therefore, I have an ugly hack where I wait until the iframe is loaded, measure its height (including scroll), then resize it so that everything fits. (I also add a little bit of padding so that if there's a horizontal scrollbar, everything still fits (I have a heuristic for the maximum height of a horizontal toolbar on most platforms); I also have another heuristic where I reflow once the main contents have loaded, but not the images, so that if images take a long time to load, which happens in corner cases, then you can still read the email, and it will reflow a second time later on). So concerning this first bit, nothing that I can do about it short of fixing 80713 (you're welcome to take a go at it!).
• The second issue is because I first ask gloda "give me all the messages in the conversation", then start laying them out. In retrospect, this is a mistake, and I should just take selected messages, launch a gloda query in the background, then immediately layout the conversation and display the selected message. After that, if more messages come into the conversation when the gloda query returns, I should just insert them in the right position without changing the scroll position (tricky, but feasible). There's the added difficulty that gloda may also return extra information about messages that were already in the conversation. Tricky too, but nothing that can't be implemented.

The second one is an optimization that I've had on my mind for at least a couple years. I just need to block, say, an entire weekend to fix it, and I've found myself not really willing to do that lately.

If you're willing to take a go at it, I'd be happy to provide guidance!

[RalfJung]

Thanks a lot for all the information! If I had infinite time, this project would certainly be on my list - but the way the world works, I can't make any promises for when and if I will have time for any additional projects...

[Drup]

To complement this, sometime, even when there is only one message in the conversation, the loading basically never ends. I think this is triggered when the message contains some html.

[protz]

I view emails with HTML all the time and the loading is fine. If you can
pinpoint the issue (launch Thunderbird from the terminal and watch our
for error messages; check Tools > Error Console) and open a new bug
here, that would probably be helpful.

On 11/30/2015 11:27 AM, Gabriel Radanne wrote:

To complement this, sometime, even when there is only one message in
the conversation, the loading basically never ends. I thinks this is
triggered when the message contains some html.

—
Reply to this email directly or view it on GitHub
#1014 (comment).

[loub]

Hi,
I have been noticing the same issue lately.
From your comment, you seem to say that it has always been there.
But I feel like it started appearing only lately (like maybe in the last 6 months, but nothing I can really measure).

Anyway, it became kind of annoying so I deactivated the extension to see the difference.
And it is indeed much faster.
The main thing I miss about it, is not being able to see the e-mails I sent grouped with the ones I receive.
Do you know a way of doing that? Maybe a workaround? Or another extension?

Anyway, I have been using this extension for a few years, and very happy with it (apart from this issue), so many thanks for that!

[GuillaumeHM]

Hello all,

I'm using TB (52.6.0 (64 bits)) at work with Conversation (2.13.4) and I'm facing same issue as the second point described by @protz at top of this thread.

Thousand mails after thousand mails in my folders (more than 11000), displaying a conversation takes more and more time averagely speaking. For example, it frequently takes 9 sec.
Count of mail recipients also seems to impact time to display. For example, a conversation with one meeting invitation with a looot of recipients can take 17 sec to be displayed (same TB config and amount of mails). There is 315 recipients in this invitation.

Did you guys found out a way to fix this behaviour ? Otherwise I will sadly be forced to disable this plugin after passing over a limit some day...

I also see bug #1013 which really seems to be a consequence.

I take the opportunity to thank you so much guys for the new UI which get near what I got with my ugly local css patch in the past. The only thing I miss is buttons instead of HTML links, but I can deal with it :)
Thank you !
Guillaume

[sbernard31]

The same here, TB (52.8.0 (64 bits)) with conversation (2.13.4).

Displaying a conversation with 60 mails could take ~15s, this make my computer (Intel® Core™ i7-7600U CPU @ 2.80GHz × 4 + 16 Gio) overloaded ... (almost all the core to 100%, fan speed to max)

Except this issue this extension is really great ! I didn't understand why this is not the default UI for Thunderbird.
Do we have the same constraints/issue (explained in #1014 (comment)) if conversation was in "Thunderbird core" ?

[Standard8]

I believe this is now much improved after the recent rewrite of Conversations. We've changed how the display mechanisms work and that seems to help a lot.

We're still waiting to receive all the messages from gloda as per @protz's previous comment, but overall I believe this is better.

If it is still bad for people, I'd appreciate knowing the numbers of messages and time to display.

[GuillaumeHM]

Sorry, I can't tell you because I moved to other company where I don't use Thunderbird... Hope anyone else can give you more stats.

[Standard8]

I've not had more responses, so I'll close it out for now. I think it is improved, though obviously could get better still, and we'll be able to hopefully work towards that more once the current writes are done.