[qutebrowser] Multi web engine support in the future

[Jay Kamat]

Florian Bruhin writes:

> - Chromium embedded framework (CEF) [1][2] - has Python bindings[3] with
>   Qt integration[4], so the only one which would be reasonably possible
>   to integrate with qutebrowser. However, I don't see much benefit over
>   QtWebEngine, seeing that both are based on Chromium, and I'm not aware
>   of any killer features (like Chromium extension support) which would
>   be a good reason to look into it.

One killer feature would be avoiding qtwebengine bugs (if cef is any better).
Currently, the qtwebengine backend is about as painful to use as qtwebkit for
me (and trending worse, ever since qt 5.7). I don't think cef is in any repos
though, so it's probably not practical for most people.

>> In many cases, I found bugs in patches I submitted by running them
>> against QtWebKit (that affected QtWebEngine in subtler ways) and vice versa,
>> so to me, even if no one uses QtWebKit it remains useful.
>
> Do you have examples for that?

I find that qtwebkit is more aggressive on cleaning up resources on the C
side. Running a trivial manual/automated test in qtwebkit for a behavior often
exposes use-after-free bugs.

The most recent one is this commit:

https://github.com/qutebrowser/qutebrowser/pull/4498/commits/128d17fe91db7fb1819d741c0aab072934abb3bb

Of course, there are other cases as well, I've seen qtwebkit tests catch other
random bugs (which were bugs on the webengine side too but untested or
flakey).

>> The multiple backend approach works because there are multiple backends
>> supported through similar (and in some cases, the same) PyQt5/Qt apis. Adding
>> support for another engine would be pretty difficult as you would need to
>> integrate it into both qt (and PyQt5).
>>
>> I think it would be extremely difficult to add support for a renderer not
>> integrated into qt, as qutebrowser is heavily dependent on qt for many things.
>
> If you check the CEF example[4] it's actually not that bad - in brief:
>
> - Integrate the renderer's main loop with Qt (or configure it to run it
>   its own thread, like I think done there).
>
> - Get the renderer to render into your window, by giving it a low-level
>   window handle like in that example, or by providing it with an OpenGL
>   thingy (surface?) to render on (which is what QtWebEngine does with
>   Chromium, I think).
>
> - Dispatch some events like the window being moved/resized to the
>   renderer.
>
> - Depending how things are implemented, dispatch input events as well,
>   if Qt is getting them instead of the renderer (doesn't seem to be
>   necessary in the CEF example).

I don't think that's necessarily the hard part. The hard part is syncing up
the entire API so everything works seamlessly. Since the QtWebEngine/WebKit
apis are large, this isn't trivial. That looks like a bare minimum
implementation, but for proper integration into qutebrowser there are many
more APIs that need to be exposed for everything to work as expected.

>
>> It would probably be easier to just update QtWebKit to use a newer version of
>> WebKit.
>
> I doubt it. Doing that is not something a single developer is able to
> do, as we saw with QtWebKit. Annulen isn't the only one who seems to
> have given up either: https://github.com/annulen/webkit/issues/775
> Like said above, I don't have any hopes of it happening without a
> company picking it up (which doesn't seem to be happening either).

Updating QtWebKit must be easier because it's the exact same task (porting
webkitgtk or plain webkit to qt) with a huge advantage - it already has a
working example on an older version. (non chromium) browser engines don't have
that advantage.

There are several browser wrappers floating out there that are maintained by
small groups - see this project for an example. The problem is that no one
cares enough to maintain qtwebkit at the moment, not that it's a
monumental/impossible task.

https://github.com/zserge/webview

In some ways, qtwebengine is maintained even worse than qtwebkit, as it has
multiple bugs which have never been present in qtwebkit, and it is struggling
to add features which have been present in webkit for a long time.

https://bugreports.qt.io/browse/QTBUG-65223
https://bugreports.qt.io/browse/QTBUG-67434
https://bugreports.qt.io/browse/QTBUG-51192
https://bugreports.qt.io/browse/QTBUG-50995 (although this is hopefully done)
https://bugreports.qt.io/browse/QTBUG-62957
https://bugreports.qt.io/browse/QTBUG-51772
https://bugreports.qt.io/browse/QTBUG-68224 (fixed, but really!)
- Lack of a 'DomContentLoaded' signal on the cpp side
- White flashes on page load (seems to be getting worse every release)