Our great sponsors
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
qtwebkit
Discontinued Code in this repository is obsolete. Use this fork: https://github.com/movableink/webkit
-
webview
Tiny cross-platform webview library for C/C++. Uses WebKit (GTK/Cocoa) and Edge WebView2 (Windows).
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
https://github.com/qutebrowser/qutebrowser/issues/58 - but many things probably can't be done, or only in a hackish way (e.g. by qutebrowser reading/manipulating those internal Chromium files, before it starts up fully).
You can however remove ~/.cache/qutebrowser and ~/.local/share/qutebrowser/webengine/ manually.
> The ultimate goal would be some way to replace the functionality of "Temporary Containers" or alternatively "Cookie Autodelete" (you keep all the history, but everything else is in Incognito mode except for whitelisted sites.)
Via qutebrowser's `--temp-basedir` (or `--basedir`) flag, you can already start an isolated instance - but indeed the history won't be shared with the main instance (and neither will e.g. the config, but there's the --config-py flag).
There are also some "profile managers" which are based on the `--basedir` flag: https://www.reddit.com/r/qutebrowser/comments/l6zj0z/compari...
Finally, I'd indeed like to have a container-like feature integrated into qutebrowser itself in some way: https://github.com/qutebrowser/qutebrowser/issues/4102 - automatically switching containers based on the URL unfortunately won't be possible, but I think even just launching a new window with a different storage path (i.e. profile) would provide a lot of value.
> Can't disable WebRTC (= unique device id can always be tracked)
I think to fully disable it, you'll need to rebuild QtWebEngine. As far as I know, this is a Chromium limitation. Can you elaborate on "unique device id" though? I'm only aware of WebRTC leaking internal IPs, which can be prevented via the `content.webrtc_ip_handling_policy` setting.
> Great project, keep it up :)
Thanks for all the feedback, I really appreciate it!
I agree, all approaches to this have some kind of major drawback. The main pain point with the approach chosen by qutebrowser is probably missing support for WebExtensions (i.e. Chrome/Firefox extensions), though I still hope that'll change with QtWebEngine some day: https://bugreports.qt.io/browse/QTBUG-61676
Other similar projects are using WebKitGTK, or indeed Electron: https://vieb.dev/ - again, probably not better/worse than QtWebEngine, just a different set of problems.
qutebrowser actually has an abstraction layer over the backend (which is why it can support QtWebEngine and the older/outdated QtWebKit, with little effort needed to keep support for the latter). If there is some new kind of library appearing some day which can draw to a Qt window and used from Python, it'd totally be possible to add support for it to qutebrowser without too much effort.
I had hoped for Servo to fill that gap at some point, but so far that hasn't happened yet: https://github.com/servo/servo/issues/27579
Another possibility is for Geckoview to be ported to Desktop platforms some day: https://mozilla.github.io/geckoview/ - something the people behind Tridactyl would like to happen: https://tridactyl.xyz/ideas/#port-geckoview-to-x86_64
As for extensions - other replies to your comment already mention this, but the main problem is that the WebExtension API is very constrained. On top of that, there's no API for handling keyboard input, so those extensions work by injecting JavaScript code handling keyboard inputs into every page you visit. That works, but only barely - lots of hacks are required for those kind of WebExtension limitations, and they won't work on pages where Mozilla decides extensions can't inject JS (such as internal pages or the Mozilla addons page). Again the folks behind Tridactyl have some ideas on how to improve the situation, but so far this hasn't happened yet: https://tridactyl.xyz/ideas/#write-a-keyboard-api-for-firefo...
> I hate that it's based on Chromium though
There aren't really many alternatives. The main one is WebKitGTK, but that comes with its own set of issues (mostly performance/compatibility). You can use qutebrowser with QtWebKit as well, but I wouldn't recommend it - it's based on a 2018 WebKit with many known security issues: https://github.com/qtwebkit/qtwebkit/releases
I had hoped for Servo to fill that gap at some point, but so far that hasn't happened yet: https://github.com/servo/servo/issues/27579
Another possibility is for Geckoview to be ported to Desktop platforms some day: https://mozilla.github.io/geckoview/ - something the people behind Tridactyl would like to happen: https://tridactyl.xyz/ideas/#port-geckoview-to-x86_64
> and Qutebrowser privacy related settings also seem quite limited compared to Firefox... (and even compared to Chromium.)
Can you be more specific? Pretty much anything that's possible to expose (either via a QtWebEngine API or via Chromium commandline arguments) is exposed. Certain things (like deleting cookies belonging to a tab when it's closed) just aren't possible without implementing them in QtWebEngine first unfortunately.
FWIW there's an overview here: https://github.com/qutebrowser/qutebrowser/issues/4045
There's webview (https://github.com/webview/webview) which has bindings for many different languages, but it's a whole window rather than a UI component you can embed. It's intended to be a lightweight alternative to Electron.
QtWebEngine already detects a variety of places automatically:
https://github.com/qt/qtwebengine/blob/v5.15.2/src/core/cont...
So that flag is only needed if the file is in some strange place (like I'm guessing is the case on NixOS).
FWIW I use something similar for KeePassXC: https://github.com/firecat53/keepmenu
> But the development is slow, last major release was in Mar 2019.
I'm afraid it seems pretty much dead at this point... Looking at https://github.com/KDE/falkon/commits/master there's only a (non-automated) commit all couple of months or so. Also see https://github.com/KDE/falkon/graphs/contributors
Thanks for the answers.
> > Does it support uBlockOrigin/uMatrix?
> It doesn't support WebExtensions (i.e. Chrome/Firefox extensions) unfortunately
JFTR, uBlockOrigin available as non-WebExtension for legacy Firefox/PaleMoon.[0]
[0] https://github.com/gorhill/uBlock-for-firefox-legacy
Thanks for the detailed answer.
Many years ago, I considered adding an embedded browser (or just HTML renderer) into a game, as a simple way to build the game menu. The requirements mostly were:
- We needed the raw pixels as output. This was SDL, and the game was purely pixel based. Should also support alpha channel / transparency if possible. Also we would need to be in full control of all input events (keyboard inputs, mouse clicks), and have some easy way to handle some events like button clicks etc.
- Cross-platform (at least Windows, Linux, Mac, iOS, Android, and potentially more). Should also be easy to build, and not have much dependencies.
- It should be a small dependency (WebKit was way overkill; or maybe you can build a stripped down version?).
We gave up. Although we didn't really needed all the modern HTML features, and also no JS. I guess for a projects like yours, you have somewhat different requirements.
I wonder if it is worth it to fork an existing browser (Chromium, Firefox) for your purpose. But this is probably impossible to maintain and keep in sync with upstream.
I wonder whether there are other simple ways to hook into the browser. After all, you are in control of the OS, and you can inject some code. On MacOSX, there was actually some nice way to script things like this. But I think they restricted that very much now.
https://github.com/albertz/Pyjector
https://github.com/albertz/chromehacking/blob/master/chromeh...