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 · 34 comments
Open

Thoughts on dropping QtWebKit support #4039

The-Compiler opened this issue Jul 4, 2018 · 34 comments

Comments

@The-Compiler
Copy link
Member

@The-Compiler 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...


Please also note the update in this comment.

@slackhead
Copy link
Contributor

@slackhead 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
Copy link
Contributor

@mschilli87 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
Copy link
Member Author

@The-Compiler 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
Copy link

@ElDifinitivo 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
Copy link

@mvucBmM0 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
Copy link
Member

@jgkamat jgkamat commented Jul 17, 2018

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

@mvucBmM0
Copy link

@mvucBmM0 mvucBmM0 commented Jul 17, 2018

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

@PluMGMK
Copy link

@PluMGMK 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
Copy link
Member Author

@The-Compiler 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
Copy link
Contributor

@toofar 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
Copy link

@alabamaboner 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
Copy link
Member Author

@The-Compiler 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
@The-Compiler
Copy link
Member Author

@The-Compiler 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.

@The-Compiler
Copy link
Member Author

@The-Compiler The-Compiler commented Sep 25, 2018

Correct.

@jgkamat
Copy link
Member

@jgkamat jgkamat commented Mar 2, 2019

@The-Compiler
Copy link
Member Author

@The-Compiler 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
Copy link
Contributor

@mschilli87 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
Copy link
Member Author

@The-Compiler 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
Copy link
Contributor

@mschilli87 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.

@The-Compiler
Copy link
Member Author

@The-Compiler The-Compiler commented May 22, 2019

From qtwebkit/qtwebkit#812 (comment):

See https://www.patreon.com/annulen (note that it's still unfinished)

This might cause me to change my decision. At the very least, I definitely want to watch for a while before removing QtWebKit support, though I might still want to remove some features (mhtml downloads come to mind) which are rather complex, if they're in the way of future development.

@q66
Copy link

@q66 q66 commented Aug 23, 2019

There is another reason nobody mentioned yet, and that's actual platform support - webengine is by default limited to x86/arm (and mips i guess) because that's what chromium supports, and they don't support anything else. People with ppc hardware therefore out of luck (except ppc64le setups that can painstakingly maintain out of tree patchets with little hope of getting them upstream) as webengine is not interested in keeping extra platform support downstream and google is outright refusing it.

Meanwhile, qt5-webkit works, even on old 32-bit big endian powerbooks. And it doesn't even have broken colors.

@The-Compiler The-Compiler added this to the v2.0.0 milestone Dec 31, 2019
@alarixnia
Copy link

@alarixnia alarixnia commented Jun 10, 2020

webengine is not interested in keeping extra platform support downstream and google is outright refusing it.

I'm speaking only from the perspective of NetBSD here, since a user has made a qutebrowser package and they're unsure whether it can be moved out of the user repository due to the unclear status of support for qtwebkit.

Anything based on Chromium is a hard sell for us, because it's simply not portable to operating systems Google doesn't care about commercially, and convincing them to make life easier for the BSDs has been an ongoing struggle.

The other BSDs are carrying extremely large patch sets - in excess of 600+ files modified - just to undo the ifdef mess Google has introduced (apparently, their build system does not support feature detection). Since we have no interest in maintaining this currently, we're relying on WebKit for the foreseeable future, since it's significantly more portable.

@The-Compiler
Copy link
Member Author

@The-Compiler The-Compiler commented Jun 10, 2020

I'm aware - but 2 years after this issue was opened, QtWebKit is still based on a WebKit version from 2016 with countless security issues. Support for it is still in because the maintenance burden is relatively low (though noticable) - but at some point, either the maintenance burden will rise (still no idea how things will look with Qt/PyQt 6, for example) or QtWebKit will just be too outdated to use as a browser backend (arguably that's already the case, looking at the security issues).

@q66
Copy link

@q66 q66 commented Jun 10, 2020

qtwebkit is currently working on a rebase, so this issue should at some point solve itself - the dev version is somewhat usable and recent enough, but is still missing some things

@The-Compiler
Copy link
Member Author

@The-Compiler The-Compiler commented Jun 10, 2020

I know, and that's another reason I haven't dropped it yet - but that's been the current status for four years now. With one commit in the dev branch in 2020 edit: okay, some more in the other dev branch without -wip, I'm not too confident much will change.

@q66
Copy link

@q66 q66 commented Jun 10, 2020

it's been in a little slump for a few months, but i'm monitoring their IRC channel and it should probably pick up again at some point - i'd give them some more time...

@The-Compiler
Copy link
Member Author

@The-Compiler The-Compiler commented Jun 10, 2020

Right, that's probably what will happen anyways. If I'm going to drop QtWebKit support that'll probably be in qutebrowser v2.0.0, and that's likely going to happen somewhen after Qt 6.1 is released, i.e. around a year away (#5395).

@The-Compiler
Copy link
Member Author

@The-Compiler The-Compiler commented Jan 8, 2021

v2.0.0 is going to be released earlier than I mentioned in my above comment (and without Qt 6 support for now) - since this is definitely a bigger undertaking I'm not touching QtWebKit support for v2.0.0.

@The-Compiler The-Compiler removed this from the v2.0.0 milestone Jan 8, 2021
@The-Compiler The-Compiler added this to the v3.0.0 milestone Jan 8, 2021
@amacfie
Copy link
Contributor

@amacfie amacfie commented Feb 9, 2021

2¢: If I wanted to run a legacy browser I'd still be using Pentadactyl on Pale Moon. Ditching webkit would make contributing to the codebase easier.

@mschilli87
Copy link
Contributor

@mschilli87 mschilli87 commented Feb 16, 2021

@amacfie:

Ditching webkit would make contributing to the codebase easier.

How so? While I do not use webkit and don't plan to either, I still have hopes that there might be another engine but the one pushed by Google and knowing that qutebrowser is developed in a way that abstracts stuff away 'enough' to support different backends is a big plus for me, even if I use only one of them.
The switch from WebKit to WebEngine was quite some work and I like to believe adding yet another backend nowadays should be significantly easier than it was back than. I am afraid dropping that one alternative engine could drive development in a direction were the codebase would become too tied to a specific backend. If upstream (which includes names like Google and Qt that have quite a track record in damaging FOSS) decides to ditch supporting alternative browsers like this, I am sure some free alternatives will pop up. The question is going to be if qutebrower can adopt these before it dies. Note that I don't worry if such a switch will become necessary but just when. ;-)

@The-Compiler
Copy link
Member Author

@The-Compiler The-Compiler commented Feb 16, 2021

FWIW I agree that QtWebKit support is still around mainly because I want a second backend to ensure the abstractions work correctly. Also because so far, dropping it would be a bigger effort than continuing to maintain it, at least from my perspective. Details on that claim would indeed be interesting.

I sometimes also use it to run end2end tests because they end up running a bit faster with QtWebKit - also I think a couple of tests never really got ported over to QtWebEngine, despite not being QtWebKit-specific.

Perhaps it'd make sense to have a "dummy" backend, also for testing (and probably #724). I'd say this would even be a requirement before dropping QtWebKit. However, I'm really not sure it's worth the trouble at all, as long as QtWebKit support mostly stays out of the way.

As for:

If upstream (which includes names like Google and Qt that have quite a track record in damaging FOSS) decides to ditch supporting alternative browsers like this, I am sure some free alternatives will pop up. The question is going to be if qutebrower can adopt these before it dies. Note that I don't worry if such a switch will become necessary but just when. ;-)

I agree this could happen at some point, but the LGPL license of Chromium as well as the KDE Free Qt Foundation do a great job at ensuring it doesn't so far. I'm not sure about "I am sure some free alternatives will pop up", though. It's not like this is something a single developer could do, you do need a bigger organization behind it. The only realistic possibilities so far would be either Servo (servo/servo#27579) or an x86 port of Geckoview, both of which I don't see happening in the near future.

@amacfie
Copy link
Contributor

@amacfie amacfie commented Feb 16, 2021

How so?

Well with both webengine and webkit in there everything stuff that interfaces with the rendering engine has to be done twice.

@The-Compiler
Copy link
Member Author

@The-Compiler The-Compiler commented Feb 16, 2021

I've taken a quick look at your contributions and I could only find one place where you have a backend-specific change, with only a handful of changed lines - one which would likely need to stay even if QtWebKit was dropped, as we likely can't do all custom downloads via QtWebEngine. That code can and should be deduplicated though, see #6173.

Clearly, that's much less than "everything". Am I missing something, or are you just exaggerating? If not, again, please be more specific - perhaps there are things which can be improved before/without dropping QtWebKit, which clearly isn't a priority at the moment.

@amacfie
Copy link
Contributor

@amacfie amacfie commented Feb 16, 2021

I've taken a quick look at your contributions and I could only find one place where you have a backend-specific change, with only a handful of changed lines - one which would likely need to stay even if QtWebKit was dropped, as we likely can't do all custom downloads via QtWebEngine.

Clearly, that's much less than "everything". Am I missing something, or are you just exaggerating? If not, again, please be more specific - perhaps there are things which can be improved before/without dropping QtWebKit, which clearly isn't a priority at the moment.

That's because if a new feature or bugfix would involve a bunch of webkit stuff I generally don't pick it up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
13 participants