Thoughts on dropping QtWebKit support

[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...

[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.

[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...

👍

[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 (#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 #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.

[The-Compiler]

Reasons some people use QtWebKit over QtWebEngine:

• PDF.js support (#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 #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.

[SavoyRoad]

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.

[SavoyRoad]

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.

[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.

[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.

[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.

[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)

[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)

[toofar]

I built core-js (lots of polyfills) with esnext.reflect added to the grunt task and loaded that as a greasemonkey script, which does add a Reflect.construct function. But because we gave up on working around the page load signals and just load everything at document-end it is too late to make a difference ;_;

[toofar]

I built core-js (lots of polyfills) with esnext.reflect added to the grunt task and loaded that as a greasemonkey script, which does add a Reflect.construct function. But because we gave up on working around the page load signals and just load everything at document-end it is too late to make a difference ;_;

[alabamaboner]

The one and only reason I'm still on qtwebkit is CPU usage and RAM. I basically use qutebrowser as a web document reader with everything I can disabled (javascript, cookies, etc). The fact that the webkit version is old also helps since thankfully the ways words and pictures are displayed on the internet only change when you encounter sites that are abominations yet not the same can be said about other elements which became popular over the last few years.
I know I'm probably the only one using it like this and I completly understand the decision of dropping support for it, I just wanted to make my voice heard.

[alabamaboner]

The one and only reason I'm still on qtwebkit is CPU usage and RAM. I basically use qutebrowser as a web document reader with everything I can disabled (javascript, cookies, etc). The fact that the webkit version is old also helps since thankfully the ways words and pictures are displayed on the internet only change when you encounter sites that are abominations yet not the same can be said about other elements which became popular over the last few years.
I know I'm probably the only one using it like this and I completly understand the decision of dropping support for it, I just wanted to make my voice heard.

[The-Compiler]

Rough plan forward for this, FWIW:

• Wait for Qt 5.12 and add notification support (#3992) (going to 5.13 unfortunately)
• Add pdf.js support (#2330)
• Add process model settings to preserve RAM/maybe CPU (#4040)
• Show warning (once) about QtWebKit mentioning that QtWebEngine probably has feature parity by now.

[The-Compiler]

Rough plan forward for this, FWIW:

• Wait for Qt 5.12 and add notification support (#3992) (going to 5.13 unfortunately)
• Add pdf.js support (#2330)
• Add process model settings to preserve RAM/maybe CPU (#4040)
• Show warning (once) about QtWebKit mentioning that QtWebEngine probably has feature parity by now.

[cancercufasole]

gif loading is still as atrocious as I remember with qtwebengine, it will try to use as much cpu as possible to load it as fast as possible even with low-end device mode on always and process model to single process but overall it wasn't that bad
There's no way to currently block something like gifs through chromium flags right ?

[cancercufasole]

gif loading is still as atrocious as I remember with qtwebengine, it will try to use as much cpu as possible to load it as fast as possible even with low-end device mode on always and process model to single process but overall it wasn't that bad
There's no way to currently block something like gifs through chromium flags right ?

[The-Compiler]

@cancercufasole Nothing I'm aware of. It might be possible to expose this setting to QtWebEngine, but I don't see a way to set it via flags.

[The-Compiler]

@cancercufasole Nothing I'm aware of. It might be possible to expose this setting to QtWebEngine, but I don't see a way to set it via flags.

[cancercufasole]

That would require patching QtWebEngine tho right ?

[cancercufasole]

That would require patching QtWebEngine tho right ?

[The-Compiler]

Correct.

[The-Compiler]

Correct.