Love using qutebrowser. Really an amazing opensource browser!
The only extension necessary for me was adblocking and now it's even better!
I did/continue to have issues with qt-webengine though, like 144hz monitor with qt webengine is limited to 60hz but these things are unrelated to qutebrowser.
In fact most of my "bugs" can be related to upstream qt webengine and wayland support. I feel bad for the authors of qutebrowser for so often getting issues that is actually an upstream bug in qt. It doesn't help that qt webengine work is rather slow (imo)
There's magic about pressing "o" and typing in what you want to search from history or Google which is so fast and efficient. I have tried similar setups on other browsers but in qutebrowser the search algos are so simple and snappy, it works great. My colleagues sometimes were amazed at how fast I could navigate across the browser all thanks to this great software
> There's magic about pressing "o" and typing in what you want to search from history or Google which is so fast and efficient.
I moved from linux+qutebrowser to macos+safari a couple years ago (mostly because I needed to for my work computer and was getting tired of fighting ableton+wine on my personal computer) but I really love qb (I even wrote a blog post on it: https://jamesbvaughan.com/qutebrowser). I miss a lot of things about it, with "o" being one of the big ones.
I know that I can use qutebrowser on macos, but using safari (with Vimari) just feels more integrated with the OS and my other Apple devices, and that's been something I've enjoyed more than I expected to.
Writing this is making me think I should give qb on macos another shot though...
> There's magic about pressing "o" and typing in what you want to search from history or Google which is so fast and efficient. I have tried similar setups on other browsers but in qutebrowser the search algos are so simple and snappy, it works great.
Nailed it. I also like the fact that the search also works on bookmarks. I've the feeling that it actually helped me forget less about them.
> Love using qutebrowser. Really an amazing opensource browser! The only extension necessary for me was adblocking and now it's even better!
Yay, glad to hear that!
> I did/continue to have issues with qt-webengine though, like 144hz monitor with qt webengine is limited to 60hz but these things are unrelated to qutebrowser.
> In fact most of my "bugs" can be related to upstream qt webengine and wayland support. I feel bad for the authors of qutebrowser for so often getting issues that is actually an upstream bug in qt.
It's not that bad, qutebrowser also has more than enough bugs on its own :D
Jokes aside: If I can reproduce something myself, I'll gladly report it upstream. If possible in any way, I'll add a workaround to qutebrowser. Sometimes neither is the case, then I'll close those bugs asking the reporter to report them upstream directly.
> It doesn't help that qt webengine work is rather slow (imo)
Yeah, it is. It's a relatively small team working on QtWebEngine, and even just keeping up with Chromium changes (and backporting security fixes) is a monumental task. When they update their Chromium snapshot (a subset of the entire Chromium tree), often there are millions of changed lines, and I've heard they regularly need around a person-month or so to adjust their stable API to those changes.
Still, there are only very few alternatives to it, and there's no way qutebrowser could shoulder this kind of work directly (by e.g. being based on Chromium's source, something people did suggest in the past).
> There's magic about pressing "o" and typing in what you want to search from history or Google which is so fast and efficient. I have tried similar setups on other browsers but in qutebrowser the search algos are so simple and snappy, it works great. My colleagues sometimes were amazed at how fast I could navigate across the browser all thanks to this great software
Hehe, yeah! There's a lot of logic people want to add to that (e.g. sorting by frequency weighed in rather than just recency), but all of that has the potential of making things much less snappy. I kind of like the simple approach, but I'm also open to improving it if it can yield even better matches without sacrificing performance. It's a hard balance to strike sometimes.
Ctrl + L then "*" will search in bookmarks for firefox.
Ctrl + L will focus the url bar, and then you can use several modifiers to search different things. E.G: ? will run a search engine query, even if you type something that looks like a domain name after it, such as a file anme.
I like the way qutebrowser works and the way it avoids wasting space, and I wish I could use it. But over several versions of Ubuntu and qutebrowser, I’ve encountered too many problems; I think most are due to the qtwebengine and the fact that qutebrowser is made with Python.
The latter often leads to the familiar dependency hell when trying to install or upgrade the program.
I have frequent crashes, it’s slow at rendering pages, it uses more memory than (for example) chromium and seems to leak memory; any kind of CSS animation causes the CPU to have a major workout. After one upgrade most video stopped working.
I never cared about the ad blocker, as I use a hosts file for that. Why doesn’t everyone? It seems to be a better solution.
> The latter often leads to the familiar dependency hell when trying to install or upgrade the program.
Can you elaborate?
> I have frequent crashes, it’s slow at rendering pages, it uses more memory than (for example) chromium and seems to leak memory; any kind of CSS animation causes the CPU to have a major workout.
> I never cared about the ad blocker, as I use a hosts file for that. Why doesn’t everyone? It seems to be a better solution.
That's essentially what qutebrowser did before this release as well - but many ads and trackers are served from the visited page directly rather than a third-party host.
First, thanks for your work on Qutebrowser. I’m sure it’s exhausting in many ways, and I know it’s basically a hobby. So despite my complaints I’m impressed and I love the concept. And I’ve noticed you are consistently responsive to users, despite this not being a job.
Pip installing QB usually leads to errors about missing or wrong Python QT libraries, and attempts to install those lead to other errors. I don’t expect you to deal with these problems; it’s what I’ve come to expect with large Python programs. Using a virtual env. did not solve the issues for me.
EDIT: or it will install, but then when I run it, I get an error about something missing or being the wrong version.
The nonworking video, I’m sure, is due to missing codecs.
“many ads and trackers are served from the visited page directly”
True, but the hosts file seems to catch most everything.
Yes and no - I'm only employed for 2 days a week, and earn enough in (recurring) donation income for this to be considered a part-time job. I also do some training/consulting around Python/pytest with my company (Bruhin Software), but that's usually only a couple of days per month.
> Using a virtual env. did not solve the issues for me.
That's weird, I'm not aware of any issues like that which wouldn't be resolved by using a virtualenv. You might want to try using qutebrowser's mkvenv.py which takes care of everything (or at least tries to):
“earn enough in (recurring) donation income for this to be considered a part-time job”
Glad to hear that!
“I'm not aware of any issues like that which wouldn't be resolved by using a virtualenv.”
To be more accurate, if I recall correctly, I think it did resolve the dependency issues, but the result was that the version of QB installed this way was crashy, or there was some other problem. Sorry, I didn’t take notes. I haven’t tried mkvenv.py, thanks for suggesting that.
The hosts file solution doesn’t help with elements on a page (like cookie banners) which can load from allowed domains, or elements on a page such as YouTube ad-rolls.
But I agree about the memory usage, qute uses insane amounts of memory and it gets worse over time, I think this is caused primarily by memory fragmentation in python- but it’s more evident with large memory hungry programs like a browser.
> But I agree about the memory usage, qute uses insane amounts of memory and it gets worse over time, I think this is caused primarily by memory fragmentation in python- but it’s more evident with large memory hungry programs like a browser.
Yeah, something is leaking memory. Unfortunately, nobody has figured out what exactly yet - and everything I've seen so far is not pointing to Python (or qutebrowser) as a culprit:
“The hosts file solution doesn’t help with elements on a page (like cookie banners) which can load from allowed domains, or elements on a page such as YouTube ad-rolls.”
You’re right about that.
I’m using Chromium v.87 now and it’s the first graphical browser I’ve encountered in a while that does not leak memory. It’s fast, stable, smooth, does not peg the CPU, and I don’t need to restart it periodically to reclaim RAM.
Firefox was my main browser for a long time. But after an upgrade it starting misbehaving in some way that I don’t remember now.
It seems to be difficult to generalize about these things. Someone will say that a particular version of a browser leaks memory, or pegs the CPU, and someone else will say that the same version has no problems.
> It seems to be difficult to generalize about these things. Someone will say that a particular version of a browser leaks memory, or pegs the CPU, and someone else will say that the same version has no problems.
FWIW that's indeed my experience with qutebrowser as well. Everyone seems to have rather different experiences (or expectations?) when it comes to performance and RAM usage. Doesn't exactly make it easier to track issues down, unfortunately.
Yeah, I realize just saying “it leaks memory” is useless to you in tracking down why. It could be due to any of a dozen different things that QB interacts with. And the next level of investigation is something that I don’t really have the skills, nor, probably, the time, to undertake.
I'm not blaming you for that - those things are insanely hard to track down in a complex application spanning multiple programming languages and approaches to memory management... Unfortunately I have no idea where to start either :-/
If you’re into programs with Vim-like key bindings, I can wholeheartedly recommend Qutebrowser. Back when Firefox transitioned from the old extension system and Vimperator stopped working, I started using Qutebrowser instead. I stopped due to the lack of good ad blocking, but sorely miss the key bindings every day. Will give it a new try now!
I use qutebrowser and Firefox + Vimium (as a lightweight layer of vim functionalities on top of Firefow). You may look a it but a little bit of configuration is needed to homogenize the keybindings between qutebrowser and Vimium.
I owe this a try as well. For me, vimperator/pentadactyl was an absolute dream. I kept them running for a long time, but eventually had to abandon them along with the old firefox versions. The WebExtension imitations don't even come close.
Donated to this project a while back, first FOSS project I donated to. Worth 10x as much. No Vim keybind extension even comes close to how well it works for me. Only downside is that sometimes I need to go to chromium/ff for websites that don't work with QB's webengine.
As for sites not working, if there isn't an issue about them yet, please report them! Often all that's needed is either a faked user-agent or a small JavaScript snippet:
Any reason my Antivirus considers it a problem?
"
C:\Program Files\qutebrowser\qutebrowser.exe is infected with Gen:Variant.Mikey.118185
"
This is with Bitdefender.
If the Anti Virus spits out something with "Gen" or similiar in the name it's some atodetection bullshit and you should take it up with your antivirus vendor instead of botherung anyone else.
>This release integrates Brave's Rust adblocking library if the "adblock" Python library is available.
I can't parse this. It's a Rust library in a C++ browser but you need a Python library to use it?
Beyond that and given how glitchy Tridactyl is on firefox I'll be sure to check this out. I'm just a bit bummed that it's yet another chromium-based browser, but I guess there's no real viable alternative these days.
Sounds like a display driver issue. Make sure to run a system upgrade and reboot.
Some Nvidia users reported success after switching from nouveau to proprietary drivers. If you're (understandably) unwilling to change out your display drivers for a single application, you might want to try forcing software rendering in qutebrowser via the config [1]
It's both. PyQt are python-bindings to the Qt-code in C++. Python acts here mainly as the clue-language to connect and control the parts in C++, and other parts like this rust-based adblocker. It's a funny melting-pot...
Yup! So far, we have C (Python runtime), C++ (Qt), Python (qutebrowser itself), Rust (adblocker) and JavaScript (web stuff and some of qutebrowser's code) involved. Probably some other small things I'm not thinking of right now.
It's... challenging sometimes, but still working surprisingly well overall.
- I read many complaints about QtWebEngine. Is there still no good alternative to this? In general, when you want to embed a browser in some GUI app. There have been lots of attempts to solve this in the past. But it seems like this is not really solved. And making this cross platform makes it more difficult, obviously. I thought now that we have Electron, this should maybe be easier? (I remember, on Windows, it was quite easy to embed an IE browser component in your app, even in the 90s. And this worked well. Only problem was that it was IE, and Windows-only.)
- You could go the other way around, and write an extension for an existing browser (Chrome, Firefox). There are also already a couple of such extensions which have similar goals as this project (keyboard-focused, minimal GUI). Why is this also suboptimal, or why does this not work as well? Why is the approach by qutebrowser better? (Some comments here seem to suggest that.)
> Why is this also suboptimal, or why does this not work as well? Why is the approach by qutebrowser better?
Building a browser extension will always have limitations.
For example, if you download a file, you usually don't have a way to open/delete/retry it through a keyboard command or an extension. Or moving tabs around between windows, change the order in the current window. You have to go back to using the mouse for many tasks, even with extensions.
Browsers also have a lot of minimal chrome UI which you can't get rid of with an extension. (a while ago, I did use Safari in a mode where it only had the very thin top bar, but it wasn't super practical sometimes because it was not the intended use-case)
Having qutebrowser built with the vim-like mode as first-class citizen gives more control over what can be done and how it looks.
I've been using it for a few years now and love the keyboard-shortcut centric aspect (I also use Vim) and the minimalism and customizability of the UI.
- I guess it depends on your environment. I run qutebrowser in Debian testing and I have no issues with QtWebEngine. What specific issues have you had?
- I've tried these but they fall short most of the time. The JavaScript of the website interferes with the extension trying to grab key presses, the UI of the browser is not navigable with the keyboard or it uses its own shortcuts, and webextensions being restricted on some special pages (like about:config). The keyboard mode really needs to be a first-class citizen in my opinion.
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.
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...
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.
Whoops, I forgot about the other things I wanted to reply to :)
> 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.
Yeah. People have suggested that in the past, but keeping up with e.g. Chromium is insane. When QtWebEngine updates their Chromium snapshot (a subset of the entire source) all couple of months, we're talking about millions of changed lines, and I've heard they need around a person-month every time to adjust their stable API to that.
It's pretty much a commit all couple of minutes, almost around the clock.
> 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.
But I suppose the kind of UI/UX you could build with that would still be quite limited, perhaps even more so than what WebExtensions like Vimium or Tridactyl can do.
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.
Another QtWebEngine based browser is Falkon[1], part of the KDE project. It works well for most websites which stick to standard web development practices, has built-in ad blocker and the reason to use it would be in memory constrained environments as QtWebEngine seems to be quite memory efficient.
But the development is slow, last major release was in Mar 2019.
Will check it out. By 'crashier' do you mean the browser crashes or the website fails to load? If it's the former, then I don't remember Falkon ever crashing.
I'm really a fan of keyboard driven browsing (currently sticking with chromium + vimium) so I'll give a try to qutebrowser and would be cool if not only has adblocking but uMatrix and password manager extensions so that it can become more of a daily driver while staying snappy.
Password managers are supported via scripting integration. GNU pass, lastpass, keepass, and bitwarden are all supported, you just need to have the respective local CLI client installed.
Qutebrowser is so awesome! Sadly, I had to switch back to Firefox and Vimium because I never figured out how to enable Kerberos. With Firefox, this easy, go to about:config and edit the negotiate auth whitelist. I tried to set all kinds of flags but gave up after a couple of days.
I'm building it now with PyQt from source on ubuntu-20.04 since PyQt5-sip is missing from OS packages. Isn't this (a 50-minute build time on a popular distro) seen as a big barrier to adoption ?
Arguably this is a Ubuntu (Debian?) packaging bug. Upstream recommends using "PyQt5.sip" ever since PyQt 5.11, yet Ubuntu seems to package PyQt 5.14 but retaining the old "sip" name.
There's an option there to install a binary Qt/PyQt from PyPI, so you don't need to build anything from source. However, note that it comes without proprietary codec support.
I added the patch for the `--desktop-file-name` flag. It's useful for profile management on Linux. I wrote up a comparison of a couple profile managers for Qutebrowser here:
Mozilla is actively hostile to anything that smells like "libfirefox". This is a big part of why they killed xulrunner.
This is really sad. IMHO their adoption numbers would not still be plunging if people had a way to insulate themselves from the large, random, and often undesired changes in the UI that are forced upon users with each Firefox security update.
I suspect mainly technical. Chromium is already embedded everywhere, Gecko a lot less so (I can't even come up with a single modern example, although I'm sure they have to exist). There's probably a lot fewer resources and support if you decide to go the Gecko route.
I also vaguely remember reading somewhere that Gecko is a lot harder to work with for third parties due to unstable APIs and frequent breakage, but don't quote me on on this.
You're technically correct, because they use Blink, which is a descendant of WebKit.
I'd say it's about as pendantic as insisting that Windows 7 is built on top of Vista as opposed to XP. The prior statement is certainly more direct and strictly accurate, but that doesn't mean the latter statement is automatically false.
I don't know how to respond to this except to say that anyone operating on either the assumption that Chromium uses WebKit or the belief that Blink being a WebKit fork means that it makes sense not to consider them sufficiently distinct is mistaken one way or another.
People will act like the prospect of maintaining private forks of NPM modules is a major crisis, but then convince themselves—or let other people get away with convincing themselves—that 8+ years of diverging development involving two software giants' investments of billions of dollars of engineering resources poured into implementing their vision of what is one of the most complex and complicated undertakings that exists in software development is somehow no big deal.
(And that's not what "pedantic" means. Both this parenthetical and your comment are examples of pedantry.)
I actually agree with you. That probably prompts the question: "how on Earth could you possibly hold both of these stances simultaneously without being a big, fat phony?".
Yeah... okay, admittedly it probably doesn't prompt that question because you have better things to be doing, but I have nothing better to do, so I'll explain myself anyway!
The comparison to 7/Vista/XP was not accidental. As you may know, there is an 8 year time gap between the release of 7 and XP. Moreover, Vista was a huge transitional change. Under the hood, 7 and XP are different animals, even if they do share common ancestry and deliver the same baseline functions.
Taking these things into consideration, it's not terribly pedantic to insist that Windows 7 is, in fact, built on top of Vista and not XP. It's still a hair pedantic, but only in the context of this fact being used to correct someone with a less strictly correct (although, I insist, still true) interpretation. That's the feeling I was trying (and failing) to convey with my comparison, which happens to actually be in agreement with your counterpoints.
> there is an 8 year time gap between the release of 7 and XP
Which is why the metaphor is off. Safari+WebKit and Chrome+Blink are being developed in parallel and competing with one another. They're not two releases in the same product line where one is the dead forebear and the other a successor.
> it's not terribly pedantic to insist that Windows 7 is, in fact, built on top of Vista and not XP
What? That wasn't the topic. None of this is relevant.
The topic is which engine Chrome is using. Explaining that Chrome doesn't use WebKit isn't pedantic. However, when someone does explain it, for someone else to appear and point out that the engine it uses is forked from WebKit—a nugget of information that changes nothing about the discussion—is pedantic.
I think you're responding at this point for the pleasure of feeling like you're having a conversation, or you're still misinformed about which browsers use which engines. WebKit is not Blink, and Chromium is using the latter, not the former. That's the whole point of this entire digression.
The Qutebrowser dependency list says it can use either QtWebEngine (Chromium) or QtWebKit (WebKit):
> QtWebEngine, or alternatively QtWebKit (5.212) - This is not recommended due to known security issues in QtWebKit, you most likely want to use qutebrowser with the default QtWebEngine backend (based on Chromium) instead. Quoting the QtWebKit releases page: [The latest QtWebKit] release is based on [an] old WebKit revision with known unpatched vulnerabilities. Please use it carefully and avoid visiting untrusted websites and using it for transmission of sensitive data.
To use Geko (or hopefully Quantum) with Qutebrowser you would need a nice QT integration. Poking around a bit, it looks like Mozilla and Nokia did some work on this in 2008, but it doesn’t seem it ever got out of beta:
My question still stands. If webkit is a bird and gecko is a reptile, then why are there (relatively) so few reptile browsers? Is it easier to embed engines from the webkit family, or are they popular because chrome and safari are popular?
The major players of the industry have DRM keys, and browser competition is hindered by only allowing access to DRM protected contents to some other vetted major players.
Nasty situation. But I guess it makes sense from the POV of the entities that want to protect their contents with DRM (if DRM was opensource... its use wouldn't make much sense)
For some reason, DRM support works just fine (at least last time I tested) with QtWebEngine if it's available (e.g. because Chromium/Chrome is installed on the same system).
This seems relatively unlikely, mainly because the drm issues are likely related to widevine, which google is notoriously picky about who they allow to use it
For some reason, it works just fine (at least last time I tested) with QtWebEngine if it's available (e.g. because Chromium/Chrome is installed on the same system).
This is nothing qutebrowser can fix - DRM/Widevine support is something done entirely by the underlying QtWebEngine and Chromium code.
It's a bit of a pain to set up, but it should be possible to get it to work. Basically, you'll need to get an older Chrome version (corresponding to whatever Qt version you're running), extract the needed .so files from there, and then put them in the right place so QtWebEngine picks them up. Unfortunately, there's almost no feedback when it doesn't work.
Qutebrowser runs on top of Blink, which is the same guts that are in Chrome. So if Widevine is packaged for some other browser that is available on your distro, you can pass in the QT arg
and it should work. This even works on NixOS, although you have to pull the relevant path out of the Nix store, and I don't know a good way to do that automatically that can fit inside a qutebrowser config.
I really love Qutebrowser. I'm mostly missing autofill/password manager integration, but that's because I'm too lazy to learn to write scripts for this.
I sometimes feel lost at work without it, and even Vimium doesn't feel as good to me.
I'd be glad to get ideas from anyone willing to share confs.
And the unbeatable openness and availability of The-Compiler is
really appreciated!
> I really love Qutebrowser. I'm mostly missing autofill/password manager integration, but that's because I'm too lazy to learn to write scripts for this.
I really like this browser. The reason I don't use it is kind of silly: Scrolling with j/k works so much more nicely with vimium in firefox. It's such a small complaint, but it really is what is keeping me away.
It looks really cool, will definitely check it out;
I hate that it's based on Chromium though, and Qutebrowser privacy related settings also seem quite limited compared to Firefox... (and even compared to Chromium.)
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
> 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.
Thanks for your reply, the basic things i was missing at a first glance:
- Could not find a way/command to simply clear ALL the cache (cookies, cached images and files, Database storage, etc.)
- 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.)
- Can't disable WebRTC (= unique device id can always be tracked)
I can understand the choice for Chromium btw. Although i can't bring myself to using/supporting Google's monopoly... so i'll stick to Firefox as my main browser.
> Could not find a way/command to simply clear ALL the cache (cookies, cached images and files, Database storage, etc.)
That one is indeed because most of those things are opaque to qutebrowser. They're handled by the underlying QtWebEngine/Chromium, and only for a few of those things there's a way for qutebrowser to delete them. There's an issue about it here:
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).
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!
If anyone has any hints on getting qutebrowser to not suck up battery and CPU on macOS Big Sur it would be much appreciated. Maybe things will smooth out in 2.0?
Some of those issues might be caused by the underlying QtWebEngine. For others, qutebrowser might be responsible (I'm mainly thinking of https://github.com/qutebrowser/qutebrowser/issues/5376 which might be relevant).
In my day-to-day work, I only use Linux - so the Windows/macOS releases are pretty much "best effort" I'm afraid, until someone steps up to fix platform-specific issues there.
I'm afraid I don't really have much news to share about that. It requires a complete rewrite of session handling and the on-disk session format, and that's just something I haven't gotten around to finishing yet.
Thanks for the reply, The-Compiler, and for your project.
I assumed my problem was related to the QT issue because it started at the same time, but I was wrong. It's just a configuration mistake. I had `session.default_name` set to no value, and because I typically exit qutebrowser with "ZZ" (`:quit --save`), the last session I created was getting overwritten by the contents of my last-viewed windows.
Wouldn't have checked if you hadn't responded. Very grateful.
However, the new built-in adblocker does a big part of what uBlockOrigin does. As for uMatrix, there's https://gitlab.com/jgkamat/jmatrix (though it's a rather unofficial hack, and I have no idea if it still works with v2.0.0).
I did/continue to have issues with qt-webengine though, like 144hz monitor with qt webengine is limited to 60hz but these things are unrelated to qutebrowser. In fact most of my "bugs" can be related to upstream qt webengine and wayland support. I feel bad for the authors of qutebrowser for so often getting issues that is actually an upstream bug in qt. It doesn't help that qt webengine work is rather slow (imo)
There's magic about pressing "o" and typing in what you want to search from history or Google which is so fast and efficient. I have tried similar setups on other browsers but in qutebrowser the search algos are so simple and snappy, it works great. My colleagues sometimes were amazed at how fast I could navigate across the browser all thanks to this great software
Thank you qutebrowser!