HTML support in the mimetreeparser
Open, NormalPublic
Actions

Assigned To

Authored By

	CarlSchwan
	Nov 3 2023, 12:28 PM

Description

We should probably have some html support in the mimetreeparser. Here are the following options:

Full blow Qt web engine

Issue: this doesn't work with mingw and is really big

Unfortunately Qt WebView on windows and Linux also use internally QtWebEngine and only uses the native browser on mac, ios and android.

Use a smaller web engine

litehtml: there is an existing Qt wrapper for it called qlitehtml and used by QtCreator. No idea how well maintained it is
servo: use rust which might or not be an issue. It is now again well maintained but not sure how embeddable it is and if we can limit network connectivity
laddybird: also has qt integration but not sure how embeddable it is and if we can limit network connectivity
webkit: Qt Webkit is dead but WPE WebKit is actively maintained but seems more targetted at yocto/embedded.

litehtml looks the most promising in term of amount of work we need to do from all these alternatives.

Use QTextDocument

Currently we use QTextDocument but only to render the plain text part, we could also render the html part too if we detect that it is not too complex with QTextDocument which should better preserve the formatting.

Open in external browser

We could add a button to open the html part in the browser if we detect that there is alternative html part

Related Objects
Search...

		Status	Assigned	Task
		Open	CarlSchwan	T6199 Kleopatra: MIME viewer support
		Open	CarlSchwan	T6795 HTML support in the mimetreeparser

Event Timeline

CarlSchwan triaged this task as Normal priority.Nov 3 2023, 12:28 PM

CarlSchwan created this task.

For now I am for the KMail approach with QTextDocument. So if we have multipart/alternative show a button that HTML is available and then the user can decide (e.g. if the mail is validly signed) to render the HTML part in QTextDocument. This might give us also an idea how well this works overall. And then let us wait for now until we get to the real GpgOL.js use case. For the customer we talked today is a bit special in that he mostly wants to have a way to view decrypted mails in Outlook. That is something we do not want to compete with.

So priority Normal for "have a way to show html in QTextBrowser" and after that move it to prio low. Our SecOps explicitly state that HTML mails should be avoided.

KMail is using QtWebEngine even for plain text content. The entire viewer is one website, which causes some security issues like content from one mail can position itself on top of the headers information with simple css.

Just tested QTextDocument for a few html emails and it works almost perfectly as long as the emails were created for the old outlook still using the html4 engine (iirc the same one as Word)

But likely won't work for more modern emails

From a "being nice to end users PoV", I think a QtWE is the best approach
From a "being nice to our selves PoV", I think QTD is easiest, alternatively having a button to open in a browser.

From a "middle ground compromise PoV", I think litehtml looks most promising. Especially since I think it can't do network at all nor javascript.

From a "hard work and insanity PoV", extend Qt's WebView to use some native html component on windows and then use that ....

With https://invent.kde.org/pim/mimetreeparser/-/merge_requests/26 it's possible to toggle between the plain text and the html content

This can serve as base for later using a better html viewer than QTextDocument: qlitehtml

One issue with qlitehtml is that it's not released and is just in Qt gitlab as playground. I don't think they want to release it as it is just used internally in QtCreator. Worse case we can always fork it as a KLiteHtml and do a release for distros. It's a quite small wrapper.

HTML support in the mimetreeparserOpen, NormalPublicActions