We'll have to support both because we care about older Linux distributions (right now, we support building against Qt 5.2). In addition to that, Trojita requires certain features which only became available in the 5.6 webengine (custom URL delegates, and detailed request filtering, for example). Patches which make this happen are welcome.

Also please note that QtWebKit is still available in Qt 5.6, they just stopped producing tarballs and the default `init-repository` build setp skips webkit. It is still getting patches at the Qt project.

QtWebKit is coming back:  http://thread.gmane.org/gmane.comp.lib.qt.devel/26208

There is absolutely no need to run multi-process monstrousity of chromium just to render HTML mail.

"There is absolutely no need to run multi-process monstrousity of chromium just to render HTML mail."

I feel just the opposite :
I compiled qtwebengine for qupzilla and rssguard, and I feel doomed when forced to compile qtwebkit -as an addition for trojita- which is no lightweight.

Before this turns into a flamewar:

Actually™, both are ridiculuously fat.
Also (but not only) given that Trojitá is a mail client and not a web browser.

One should not use html for mails itfp. and the vast majority of html-only mails are indeed spam.
For the rest, QTextBrowser is probably capable of sufficiently rendering them.


Since Jan feels required to ultimately support both khtml forks, the result will probably look like a plugin driven system with the (available anyway) QTextBrowser as defaulting failsafe.
This would also cover for the various "Whoops, setEcmaEnabled() is effectively noop. What do you mean, we interpret redirections? No, disabling forms isn't supported." security flaws in the webengines that one could imagine...

I should very much like trojita to dump any html engine,
and instead offer to open mail in external browser.

It is indeed rare that I have to open a html mail,
but when needed, I should like the html engine to be feature complete,
so I don't have to guess whether or not valuable info just don't get rendered.

QTextBrowser is fine by me IF we have the choice of opening a mail in external browser.

Please just don't let qtwebkit a required dependency :-)
Thanks !

Opening an HTML e-mail in an external viewer won't work because the majority of web browsers do not support stuff like the cid: URL scheme which is a must for dealing with HTML mail.

I agree that a perfect solution for 2016 is offering both QtWebKit, QWebEngine and QTextBrowser implementations as plugins. Patches which make this happen are welcome. However, arguing for this on Bugzilla won't make it happen any sooner.

You're right, so OK, no external browser.

In my personnal opinion, any platform that lives with outdated QT
can tolerate living with outdated trojita : trojita may dump Qtwebkit.

But Trojita should turn to any of QTextBrowser/Qtwebengine for security.
Arnaudv6

Archlinux switched to the new qt5-webkit, it works fine with trojita.

(In reply to Elvis Angelaccio from comment #8)
> Archlinux switched to the new qt5-webkit, it works fine with trojita.

Actually, I spoke too soon :/ 

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

Are there any news about this? I just setup a new Gentoo installation and just compile Trojitá – and QtWebkit is pulled as a dependency.

Using QtWebEngine instead would be nice, as I need it anyway as a dependency for Falkon. And if you ever used Gentoo, you know that neither building QtWebkit nor QtWebEngine is real fun ;-)

@Tobias: my use case is identical to yours. Falkon, Gentoo and QtWebEngine.

Trojita still requires QtWebKit. There was a very preliminary patch for adding WebEngine, but it got stalled. Patches are welcome; please note that they are not ultra-trivial (we're using custom URL schemes for IMAP access, we filter out the "regular internet" for privacy reasons, and we massage the view to fit into an external scroll area).

Hey, I'm on Gentoo, too, and it's buildable :).

Anyway, if you would like to see this happening, please contribute. You can find the old patch in Gerrit along with some review comments which were never addressed.

https://gerrit.vesnicky.cesnet.cz/r/946

(In reply to Jan Kundrát from comment #12)
> Trojita still requires QtWebKit. 
> ...
> Hey, I'm on Gentoo, too, and it's buildable :).
We are rapidly cutting down on QtWebKit revdeps and trojita is now one of very few unconditional ones left.

I would really like to help here, but I fear messing with QtWebKit/QtWebEngine is beyond my coding skills ...

Please save Trojitá! I use it almost daily and I love it. It would be shame if it was removed (from Gentoo) some day due to obsolete dependencies!

Both Trojita and QtWebkit entered their pre-removal phase in Gentoo, I guess there's no more manpower to manage Trojita anymore?

If it's so hard to make a transition to QtWebEngine ... does Trojita really need a/the fully-blown monster HTML engine? What about khtml? It's only about displaying HTML emails, no?

Before seeing Trojita disappear, I'd rather kick out HTML viewing completely and add a button "view HTML in a browser" or such!

(In reply to Tobias Leupold from comment #16)
> What about khtml? It's only about displaying HTML emails, no?
KHTML is dead and only exists in Frameworks 5 as a porting aid.

Well okay ... in a pinch, I'd stick to the minimal HTML subset Qt itself can render or whatever ... all is better than letting trojita die. There's no passable alternative (if you don't want/need KMail).

The update I gave in https://bugs.kde.org/show_bug.cgi?id=365299#c12 is unfortunately still the most recent piece of news I can share. Sorry, absolutely ENOTIME from my side at  this time, but I've heard that the QtWebEngine should support all of the features (including full URL scheme delegation that we rely on).

(In reply to Jan Kundrát from comment #1)
> we care about older Linux distributions

Would be nice if you would care about modern Linux distributions, too: Gentoo masked qtwebkit a a pe-removal step. There are rumors Suse removed it already and other distributions will follow.

(In reply to Jan Kundrát from comment #6)
> Opening an HTML e-mail in an external viewer won't work because the majority
> of web browsers do not support stuff like the cid: URL scheme

What about trojita saving the html to /tmp, then opening it with an external browser from there? I don't know the codes of Trojita but shouldn't codes for such actions be there as Trojita does exactly that when opening an email attachment?

As of 2 Aug 2021, Gentoo has hard-masked Trojitá due to unpatched security vulnerabilities in QtWebkit. Of course I can manually unmask the ebuilds and eventually copy them into a local repo when Gentoo deletes them, but I fear it's only a matter of time before someone figures out a remote-code-execution vulnerability that's exploitable via Trojitá's HTML email viewer, and with no further updates to QtWebkit indefinitely, running Trojitá is going to become a liability.

I second the sentiment that I would prefer to continue using Trojitá even without support for rendering HTML mail parts. Maybe QtWebkit can be ripped out and replaced with nothing if it's too hard to switch to QtWebEngine?

No other mail clients are even remotely usable. Trojitá isn't perfect, but it's the best there is. :(


(In reply to Thomas Rohloff from comment #20)
> What about trojita saving the html to /tmp, then opening it with an external
> browser from there?

That doesn't work because there would be no way to pass attached parts to the external browser (e.g., for images). Jan mentioned this in Comment 6.

And it's gone in Gentoo :'-(

My take on porting to qtwebengine can be found here:

https://invent.kde.org/pim/trojita/-/merge_requests/1

A big THANK YOU for working on this and for keeping Trojitá alive!!!