[kmail2] [Bug 387061] REGRESSION: Large messages don't display in the viewer pane (eg. New Tumbleweed snapshot 20171117 released!)

[Wolfgang Bauer]

https://bugs.kde.org/show_bug.cgi?id=387061

Wolfgang Bauer <wbauer at tmo.at> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wbauer at tmo.at

--- Comment #36 from Wolfgang Bauer <wbauer at tmo.at> ---
(In reply to Axel Braun from comment #35)
> Looks like the issue is back:
The issue us not really "back". Rather, it was actually not *fully* fixed, for
every possible email.

As proposed in comment#29, messagelib does use a temporary file now for larger
emails, because setting the content with QWebEngineView::setContent() or
QWebEngineView::setHTML() has a 2MB limit (see comment#5).

But the problem is that AFAICT it is impossible to know in advance how big the
message exactly is *after* QWebEngine's internal processing.

To quote from the docs:
> Note: Content larger than 2 MB cannot be displayed, because setHtml() converts 
> the provided HTML to percent-encoding and places data: in front of it to
> create the URL that it navigates to. Thereby, the provided code becomes a URL
> that exceeds the 2 MB limit set by Chromium.

So apparently your mail is an "edge case" that is smaller than 2000000 bytes
(the current threshold in messagelib), but that still becomes too large for
QtWebEngine/Chromium after the percent-encoding done internally.

Larger emails, like the one mentioned in the title, do (still) display fine now
though, because they are correctly detected as being too large.

It should be easy to fix for that particular mail by lowering the size limit,
but the lower limit may still be too high for certain other emails. OTOH,
setting it too low is not good either, as that way of displaying mails seems to
cause problems with encoding (see comment#28).

But I just noticed that the docs also say:
> If the content is too large, the loadFinished() signal is triggered with success=false.
Maybe this could be exploited as trigger for using a temporary file instead of
a size check?
Just an idea, I don't know if it's really possible to do that (it would
probably be quite tricky to implement at least, I fear).

-- 
You are receiving this mail because:
You are the assignee for the bug.