Drop QtWebKit

[The-Compiler]

So, time to talk about the elephant in the room: I don't intend to drop QtWebKit right away, but it's unrealistic that it's going to be around for years.

Note this post talks about QtWebKit 5.212, the updated thing by annulen - everything older is out of the picture for longer already anyways.

Issues with QtWebKit

• It's based on WebKitGTK 2.12 (latest stable: 2.20), which had 42 known security issues back in February 2017. Or in the words of GitHub: "This branch is 1987 commits ahead, 30026 commits behind WebKit:master."
• Even if some security fixes were backported, the last release was in June 2017, and the last activity in the repo was back in January.
• There's no isolation between pages/tabs, and no sandboxing. That means (unlike with QtWebEngine), as soon as a security issue is exploited, it's game over. Even if that changed (by integrating WebKit2 support), it'd still be inferior to QtWebEngine security-wise, and we couldn't use it anyways as PyQt isn't going to update their wrappers.
• Even if there are some new features (like fullscreen support), they are never going to arrive in qutebrowser because of PyQt.

Conclusions

In short, unless a group of people (or a company) picks up QtWebKit and it looks like it'd be maintained for a longer time (which is... unlikely?), the question isn't if it's going to be dropped, it's more like a "when".

Some conditions which are likely to make me release a qutebrowser v2.0 with QtWebKit support dropped:

• Qt 6 is released (~November 2020). At that point, PyQt 6 will be released too, probably with some changes which will make it difficult to continue supporting Qt 5 as well (which might mean I'll drop that too, at some point).
• There's no updates (or new release) for QtWebKit for another couple of months, making it more and more unreasonable to continue using it from a security standpoint.
• There's some bigger change in PyQt or qutebrowser which would make it difficult to continue supporting QtWebKit. This is vague, I know - but if that kind of thing happens, it might be the more reasonable thing to just drop it then instead of trying to delay it for a couple more months.
• Archlinux drops QtWebKit
• PyQt drops QtWebKit (even if before Qt 6)
• QtWebKit stops working on major websites due to missing web features.

The security implications also make me wonder whether I should start adding a warning when using QtWebKit, similar to what I've done before for the old QtWebKit before it was removed...

---

May 2025 update: QtWebKit support is now untested.

[slackhead]

These are all valid points.

I can't recall what options are left that are still only supported in webkit. URL based cookie control is one I can recall, but I haven't checked lately.

The only issue I had that made me use webkit (for a short time at least) was that some sites disabled some features. I think gmail gave warnings about using an older browser, and some youtube options were disabled - like using the dark background theme was one, but I found that these were fixed by changing the user agent string. This this was a long time ago though and they probably work without doing that now.

[mschilli87]

@The-Compiler

The security implications also make me wonder whether I should start adding a warning when using QtWebKit, similar to what I've done before for the old QtWebKit before it was removed...

👍

[The-Compiler]

Reasons some people use QtWebKit over QtWebEngine:

• PDF.js support (pdfjs for QtWebEngine #2330)
• Experiencing graphical glitches with QtWebEngine (the new options for qt.force_software_rendering added in qutebrowser v1.4.0 helped in at least one case)
• Resource usage (uses less RAM, possibly less CPU depending on website) - also see Add setting for QtWebEngine process models #4040
• Notifications (QTBUG-50995)
• Not trusting Google (despite QtWebEngine being a stripped Chromium and not phoning home)
• Needing to use software rendering (because of a Nouveau GPU driver, Wayland without XWayland, or graphical glitches) and the performance penalty coming with that.
• Apparently QtWebEngine crashes a lot (to the point of being unusable) on FreeBSD
• Archlinux ARM's PyQt package is broken and doesn't support QtWebEngine
• Different font rendering
• Flashing between pages when using a dark user stylesheet, though --qt-flag single-process seems to help with that.

[ElDifinitivo]

Honestly, the only reason I'm using QtWebKit at the moment is due to the nouveau bug with QtWebEngine. My laptop is about 8 years old and with a very underpowered GPU for it's time, so qutebrowser is awful to use with software rendering.

I like QtWebKit if only so that Chromium and its forks still have some competition as I feel most browsers outside of Chrome/Firefox are simply Chrome clones. Still, I know I'll stop my use of QtWebKit once I get a rig upgrade that won't force me to use software rendering.

There really isn't much else I think keeping webkit around except for supporting the poor software rendering saps like me. As long as people are aware of the issues, QtWebKit should be supported until it really becomes impossible or too much of a hassle like you said.

[mvucBmM0]

I use it for one single reason: CSS. I use a dark style sheet and it just works. With qtwebengine, when i use a dark style sheet, every time it opens a new page it flashes the original bright colors before the dark style.css applies. And apparently there is no real fix (#2912). Maybe not important for most, but it hurts my eyes a lot.

[jgkamat]

@mvucBmM0 that issue can be migitated with colors.webpage.bg. However, it seems to be an incomplete fix.

[mvucBmM0]

@jgkamat Yeah, that setting only works half of the time, unfortunately.

[PluMGMK]

Been meaning to comment on this for some time now. I guess my main reasons for using WebKit are the nouveau thing and the trusting-Google thing.
About trusting Google, I guess yeah, I'm rational enough to see that it's a stripped Chromium. Apart from trust though, it still has dependencies like BoringSSL though, and generally doesn't really fit in with the Qt build system, which I find makes it a pain to compile. I'm not sure if I've ever even gotten it to work.

[The-Compiler]

Looks like GitHub JS is broken (still/again?) with QtWebKit, not sure since how long. So "QtWebKit stops working on major websites due to missing web features" already seems to be the case...

It fails with:

[https://assets-cdn.github.com/assets/frameworks-d3288bb02aa9bc92a3638f14b7ed600a.js:1] TypeError: evaluating module github-rollup-frameworks-bootstrap: Reflect.construct is not a function. (In 'Reflect.construct(HTMLElement,[],this.__proto__.constructor)', 'Reflect.construct' is undefined)