some mails are anormally slow to load makes the interface unresponsive

[yeupou]

Hello,

Describe the bug
Mentioned in #901, the webmail is almost unusable for one user on one specific folder (work folder with lot of mails, long threads, some big attachments).

On a few threads, when the user click to load a message, it takes ages, load, but the page interface is no longer responsive. it is possible to scroll but click make no effect. Other tabs are unaffected and opening snappymail is another tab works.

I'd like to point out that the server is not under stress and on other folders, it serves almost instantly other mails. For instance, there are in another folder mails with inline 20/30 MB images that load instantly. The one that fails are 300 KB, but with dense headers -lot of msg-id references - and lot of HTML to prepare, because these users are sending in each and everymail all the earlier messages.

Even more confusing, it seems to partly affect only Firefox (whatever the mode, safe mode, with no hardware acceleration, with no mods/extensions) and not Chromium: it also takes ages for Chromium to load the message but the interface is still responsive.

It cause Firefox to sprout
[Parent 8007, IPC I/O Parent] WARNING: process 8456 exited on signal 15: file ./ipc/chromium/src/base/process_util_posix.cc:256
(which might be a pure Firefox/nvidia issue unrelated to snappymail)

The current workaround is to use the Chromium but the odd message load delay are annoying.

To sum up, it is very possible that the strange tab freeze is a pure Firefox/Nvidia bug that is unfortunately triggered when Snappymail takes too much time to load some mail for unclear reason.

To Reproduce
I unfortunately cannot provide the mails are sample as they are work/company related.

1. Manage to get long threads
2. Click on a message, take some time to load, try to click anything else. the tab is dead.

Please complete the following information:

• Browser: Firefox 109, Chromium 109, nvidia 515.86.01-1
• IMAP daemon: Dovecot
• PHP version: PHP-FPM 7.4
• SnappyMail Version: 2.25.2

Debug/logging information
(I set the logs on, restart PHP FPM but it produced nothing)
I tried to get clues for Firefox console but got no lead.

Tell me if there is anything I can provide to try to solve this.

Regards

[the-djmaze]

There is a new feature to whitelist images and it replaces showImages.
Set it to "always ask" and it might be faster.

Else i need the message (anonimised) to find out.
You can mail it to issue902@snappymail.eu

[yeupou]

I will send you an as best anonymized version of one mail that trigger the issue.

It takes more than 4 seconds to load this 420 kB message.

There are no specific images. As said, snappymail has no problem to instantly render messages with 20 MB worth of images.
Here, we have a whole 420 kB message that seems to be HTML/text message and headers.

Maybe it is related to rendering the whole discussion that no user ever cut from it's replies.
I guess the whole is rendered no matter what, even if no one is ever clicking on [•••] to show previous messages.
Could that be the problem?

On thunderbird, the same message open instantly.

[the-djmaze]

Maybe it is related to rendering the whole discussion that no user ever cut from it's replies.
I guess the whole is rendered no matter what, even if no one is ever clicking on [•••] to show previous messages.

The code for that is located at

snappymail/dev/Model/Message.js

Lines 335 to 347 in 16daa7b

	initView() {
	// init BlockquoteSwitcher
	this.body.querySelectorAll('blockquote').forEach(node => {
	if (node.textContent.trim()) {
	let h = node.clientHeight || getRealHeight(node);
	if (0 === h || 100 < h) {
	const el = Element.fromHTML('<details class="sm-bq-switcher"><summary>•••</summary></details>');
	node.replaceWith(el);
	el.append(node);
	}
	}
	});
	}

It calculates the height of the <blockquote> and if higher then 100px it wraps a <details> around it.

You could remove the part and just have

	initView() {
	}

Then we know if that is the problem

[yeupou]

Can I edit this Message.js directly (no need to compile anything?) to test?

[the-djmaze]

Can I edit this Message.js directly (no need to compile anything?) to test?

Sorry, no. You need to edit the big app.js so that is some trouble.

Here's a modified version. But due to some other new changes you can't go back to the old one.
This one doesn't disable the initView() but has the code moved so that it should be faster.
snappymail-2.25.2.tar.gz

[yeupou]

Arg, I am using your devuan/debian packages so I am a bit relectuant to overwrite the files with a tarball :(

[the-djmaze]

No problem, i will make a new release

[the-djmaze]

User -> Settings -> General -> Message View
That has a setting to disable the collapse.

https://github.com/the-djmaze/snappymail/releases/tag/v2.25.3

[yeupou]

Interestingly, with firefox on one computer that did not freeze, the message load faster than before.
On the one with IPC I/O Parent issues, it does not load at all, it stays with the loading animation. Nothing specific in the console/logs.

[the-djmaze]

It's good that it is faster then before 😄

So sad it didn't solve the crash, but now we know it's not that.
Looking around i found:

• https://bugzilla.mozilla.org/show_bug.cgi?id=1806224
• https://bugzilla.mozilla.org/show_bug.cgi?id=1806772
• https://www.reddit.com/r/firefox/comments/zjmaxy/firefox_basically_unusable_on_new_pc_but_other/

Maybe it helps you

[yeupou]

On the failing computer, thunderbird and chromium are being used as default now. I digged also the topic (but thanks for your links) and it seems there is some real mess with ndivia drivers, some version of nvidia gtx cards and firefox.

The loading issue that occurred on all computers seems better, except on this faulty computer. I wonder what it does to triggers the issue and kills the tab, but not the browser.

After further test, I am not sure the option "disable the collapse" on or off makes difference. It is faster now on computer not affected by the unresponsive interface but it is no matter the option being on or off.

[the-djmaze]

Ok, when the option has no effect, it sounds like a Firefox issue which can't be solved on our end (as it also doesn't occur on other PC's).

[yeupou]

I wonder if there is any way to reduce even more the message loading sequence. For these very long HTML messages, the loading time is still noticeable.

[the-djmaze]

Because SnappyMail cleans the HTML from malicious code, lookup images, tries to make it responsive and fix colors for dark mode, i don't think it can be much faster as it must analyze each html element.
This is done through JavaScript because SnappyMail can also parse eml attachments to see the attached html message.

This is all done in a template element so that the browser doesn' have to render it twice and as benefit it also solves some security issues.

[yeupou]

Ok, indeed with users with terrible habit of keeping in every and each mail the whole history in comment, it seems that slowdown is unavoidable.

[the-djmaze]

Ok, indeed with users with terrible habit of keeping in every and each mail the whole history in comment, it seems that slowdown is unavoidable.

You could force plain/text view, that strips all HTML and is faster 😸

[yeupou]

Yeah :-) But HTML view is still very convenient for most of the emails nowadays.

[the-djmaze]

RainLoop allowed to return max N bytes of the message, but then you have broken html messages, which is also not perfect.

Or should we add option: remove quoted text N levels deep.
So that first/second quote stays but not deeper.

[the-djmaze]

I've added this last idea for next release.
Tested on a long threaded mail here and works nicely for messages that use <blockquote>

[yeupou]

I like a lot this idea of squishing the N level deep.
I would argue in favor of keeping three levels of quote instead of two, to be on the safe side; after three levels we can be almost sure it is garbage.

And it will clean the threads of these users with terrible habits.

Will it show that history has been cut of and would it it still be possible to show the full message if need be (maybe by reloading the message with a link in the menu next to Show Source/Download as .eml?)?

[the-djmaze]

I made it so that you can set it to any number.
If you want 5, set to 5. If you want 3, set it to 3.

Default is 0 (unlimited)

[the-djmaze]

Try with https://github.com/the-djmaze/snappymail/releases/tag/v2.25.4

[yeupou]

That's perfect. The incriminated messages load almost instantly. Perfect job! Thanks

[the-djmaze]

I'm glad i could help.

[the-djmaze]

I've received a 2MB HTML and speed that up as well in #962

The issue was Squire fixContainer() that was called a massive amount of times.