Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Thoughts on dropping QtWebKit support #4039

Open
The-Compiler opened this Issue Jul 4, 2018 · 21 comments

Comments

Projects
None yet
10 participants
@The-Compiler
Copy link
Collaborator

The-Compiler commented Jul 4, 2018

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

This comment has been minimized.

Copy link
Contributor

slackhead commented Jul 4, 2018

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

This comment has been minimized.

Copy link
Contributor

mschilli87 commented Jul 4, 2018

@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

This comment has been minimized.

Copy link
Collaborator Author

The-Compiler commented Jul 4, 2018

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 The-Compiler changed the title Dropping QtWebKit Thoughts on dropping QtWebKit support Jul 4, 2018

@ElDifinitivo

This comment has been minimized.

Copy link

ElDifinitivo commented Jul 4, 2018

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

This comment has been minimized.

Copy link

mvucBmM0 commented Jul 15, 2018

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

This comment has been minimized.

Copy link
Collaborator

jgkamat commented Jul 17, 2018

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

@mvucBmM0

This comment has been minimized.

Copy link

mvucBmM0 commented Jul 17, 2018

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

@PluMGMK

This comment has been minimized.

Copy link

PluMGMK commented Jul 21, 2018

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

This comment has been minimized.

Copy link
Collaborator Author

The-Compiler commented Jul 23, 2018

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

This comment has been minimized.

Copy link
Collaborator

toofar commented Jul 24, 2018

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

This comment has been minimized.

Copy link

alabamaboner commented Jul 25, 2018

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

This comment has been minimized.

Copy link
Collaborator Author

The-Compiler commented Aug 8, 2018

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 added a commit that referenced this issue Sep 17, 2018

The-Compiler added a commit that referenced this issue Sep 18, 2018

@cancercufasole

This comment has been minimized.

Copy link

cancercufasole commented Sep 24, 2018

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

This comment has been minimized.

Copy link
Collaborator Author

The-Compiler commented Sep 24, 2018

@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

This comment has been minimized.

Copy link

cancercufasole commented Sep 24, 2018

That would require patching QtWebEngine tho right ?

@The-Compiler

This comment has been minimized.

Copy link
Collaborator Author

The-Compiler commented Sep 25, 2018

Correct.

@jgkamat

This comment has been minimized.

Copy link
Collaborator

jgkamat commented Mar 2, 2019

@The-Compiler

This comment has been minimized.

Copy link
Collaborator Author

The-Compiler commented Mar 2, 2019

@jgkamat Those distributions take months to years to update qutebrowser anyways because they aren't really maintained (GuixSD still packages v0.11.0), so I can't say I care. I doubt a fork will happen, they'll just continue shipping wildly outdated versions - not really a problem because QtWebKit is wildly outdated either way.

(They're also quite likely misguided - QtWebEngine developers debunked Parabola's license claims a while ago, but Parabola continues to not care, and even has a single issue for Chromium/Electron/QtWebEngine by now, despite those being different subsets of the Chromium code)

@mschilli87

This comment has been minimized.

Copy link
Contributor

mschilli87 commented Mar 2, 2019

@The-Compiler: Guix SD is before it's 1.0 release. Packaging is fairly easy and they have about 30% of was debian has packages with much less time and people. Once 1.0 is out ('soon') I consider giving it a spin and I'd be happy to maintain qutebrowser then. So far, I only use Guix on a server so a web browser is just not a priority for me. 😉

@The-Compiler

This comment has been minimized.

Copy link
Collaborator Author

The-Compiler commented Mar 2, 2019

Nice to see that qutebrowser is getting some love there, but doesn't change my point of view - if a distribution is fine with (only) shipping a web backend based on a 2016 WebKit (riddled with security issues), they'll also need to live with only shipping qutebrowser v1 whenever I release v2 without QtWebKit support (or, honestly - preferably not shipping qutebrowser at all, because using it with QtWebKit will only get more and more problematic).

@mschilli87

This comment has been minimized.

Copy link
Contributor

mschilli87 commented Mar 2, 2019

final off-topic comment from my side: Guix does support packages under any license via channels, they just might not make it to the official guix channel. So in case a (future) Guix SD user really wants to use qutebrowser, it and all its dependencies that Guix won't take could be provided via a community maintained channel.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.