Distros and QtWebEngine

[Kevin Kofler]

Lisandro Damián Nicanor Pérez Meyer wrote:
> Actually when it comes to the web engine it's not true. When I suggested
> to use an external ffmpeg and libv8 (javascript engine) the answer was
> directly no, simply because they are too entangled to be possible. And
> ffmpeg tends to be quite a source of CVEs...

Not to mention that we want our web browsers to not use FFmpeg at all (at 
least not directly), but GStreamer 1. Sadly, due to how deeply FFmpeg is 
entangled into Chromium, this does not look realistic for QtWebEngine. Using 
GStreamer would mean that we could ship it only with unencumbered codecs 
while still allowing our users to easily add patent-encumbered codecs, the 
same codecs would work for all applications, and there would also be an 
automated plugin installation mechanism. Chromium's hardcoded use of a 
forked FFmpeg breaks all that.

We also want our web browsers to support a JavaScript engine that has a non-
JIT fallback, because the JIT does not work on our secondary architectures. 
(For Debian, those are even PRIMARY architectures!) This is even less 
realistic in Chromium, because V8 is hardcoded everywhere, and there is no 
interest whatsoever in V8 upstream in supporting an interpreter fallback. 
This issue means anything that requires QtWebEngine in KDE will NOT be 
available on all those platforms, even if we were to package QtWebEngine. 
(It would also increase our maintenance workload if we were to package 
QtWebEngine, by requiring ExcludeArch or ExclusiveArch lists all over the 
place.)

        Kevin Kofler