The-Compiler

Ah, Verso looks nice and active, that wasn't on my radar. I kind of lost hope after a lot of embedding tracking issues and meta-issues over the years (the ones you linked is the third one I've subscribed to I think).

As for the Qt side, "ongoing effort" is quite a stretch for something that was made as a conference demo and not touched again since April: https://github.com/KDABLabs/cxx-qt-servo-webview/commits/mai...

I had no idea that existed, that's pretty cool!

I might experiment with it if they improve their embedding story, and if someone (not me) makes it work with Python and Qt.

Sadly, https://github.com/servo/servo/issues/27579 has been pretty dead for the past years.

(And before someone asks for Ladybird backend support: Same story there)

Huh‽ While running with QtWebKit still happens to work, qutebrowser has supported QtWebEngine (based on Chromium) since 2016 or so, and it's been the default since v1.0.0 in 2017. If you're still using it with QtWebKit despite the warning being displayed about it, or using a heavily outdated qutebrowser version, that's on you and not qutebrowser...

If you're running an up-to-date Qt and qutebrowser, that'll currently be based on Chromium 122 from April 2024 (with security patches up to Chromium 131).

RTL support should be as good as Chromium's for web contents (as QtWebEngine is based on Chromium), and as good as Qt's for the UI. Admittedly I never tested, but if you notice something in the UI that doesn't look right, I'd be happy to have a look and see if there's something that can be improved there.

Note that on Linux, the browser engine (QtWebEngine) is installed/updated separately from qutebrowser. They have a new feature release (updating to a new Chromium baseline) every 6 months, with patch releases backporting security fixes every 1-2 months. Not optimal, but some Linux distributions also backport security fixes as soon as they happen, which is much more often: https://codereview.qt-project.org/q/project:qt/qtwebengine-c...

Then there is the issue of "stable" Linux distributions (mostly Debian/Ubuntu) which never get those updates to you unfortunately, and don't seem to care about those being security-relevant either. Not much either qutebrowser and Qt can do about that sadly, but you can install Qt from somewhere else, e.g. from the PyQt binary builds if you don't mind losing proprietary codec support: https://qutebrowser.org/doc/install.html#tox

As soon as a new Qt/PyQt is out, there is usually also a new qutebrowser release bundling it for Windows/macOS releases.

Thanks for the nice words! :)

Ah, I see. That's not due to the Chromium version though, it's because the Chromium that comes with Qt releases (which is what's shipped in qutebrowser releases) is built without proprietary codec support.

Unfortunately, support for proprietary codecs like MP4 and such requires building Qt from sources, and would also require me to acquire licenses for them all (I believe they're free until a certain number of distributions, but also with all the indirect ways you can get qutebrowser, I can hardly even provide that information).

This isn't an issue on Linux, because those licenses have some sort of exception in the sense of "if shipped with an operating system or its packages".

Homebrew seems to build its Qt packages against system ffmpeg with proprietary codecs enabled, and there's an issue open which would at least allow you to build a custom build against that: https://github.com/qutebrowser/qutebrowser/issues/4127

Maybe I should look into whether I'd be allowed to redistribute such builds (or what kind of paperwork I'd need to do for it). Unfortunately there's a lot on my plate, and macOS/Windows are admittedly somewhat second-class citizens as I don't use those myself.

I’ve stopped using qutebrowser because it has some limitations due to be a bit behind on the web engine, which leads to problems with some sites.

Assuming you're on Linux, that's usually more of a problem with Linux distributions being behind on QtWebEngine. Though yeah, sometimes things are tight with QtWebEngine only updating their Chromium baseline once every 6 months. I try to ship workarounds (in the form of polyfills) with qutebrowser when I know about breakage, but usually for me things run smoothly.

FWIW there are Windows/macOS builds too.

The devtools let you do that FWIW.

See https://github.com/qutebrowser/qutebrowser/issues/8389 - unfortunately there's a lot of stupid false-positives especially with PyInstaller (packaging a Python application into an .exe). Happens a few times a year, unfortunately there isn't much I can do other than submitting a report to Microsoft and hoping they'll react ¯\_(ツ)_/¯

<3

You might like Firenvim or Wasavi:

https://github.com/glacambre/firenvim https://github.com/akahuku/wasavi

qutebrowser (and some others) also allow spawning vim from inside a text area, and reading the result back when the file is saved. I know Tridactyl can do it via its native messaging integration, but I suppose Vimium doesn't offer that.

Nyxt[1] caters to emacs people (being extensible in Lisp and all that), but personally I'm somewhat wary of it: They handled a critical security vulnerability[2] quite badly a few years ago, and the project seems to get more and more commercialized.

Webmacs[3] used to be around for a while, but is pretty dead nowadays.

I know of various emacs users who use qutebrowser, and its keybindings/configurations are flexible enough to make that work. The docs have a couple of suggested configs[4].

[1] https://nyxt.atlas.engineer/ [2] https://jgkamat.gitlab.io/blog/next-rce.html [3] https://github.com/parkouss/webmacs/ [4] https://github.com/qutebrowser/qutebrowser/blob/main/doc/hel...

DRM should work just fine via Widevine if you have a Qt build with proprietary codec support, and you have an appropriate version of Widevine available.

See https://doc.qt.io/qt-6/qtwebengine-features.html#html5-drm

The majority of security issues in browsers is in the more low-level components (rendering engine, sandbox, network stack, JS runtime, etc.). None of those small browsers implement any of that themselves, they either build on top of WebKit (e.g. via WebKitGTK, like Luakit), or on top of Chromium (via QtWebEngine like qutebrowser, or via Electron like Vieb).

So you'll mostly need to focus on keeping that up to date. Some distributions (Debian/Ubuntu for example) unfortunately do a bad job at that, but you can also quite easily install them as a binary from upstream.

You still will lag behind a bit on security fixes compared to Chromium directly, that's true. In the case of QtWebEngine, they backport security fixes to the next patch release, and I know of some distributions (I think it was Fedora?) that continuously backport those before Qt releases.

That leaves you with any security issue that's e.g. in the UI, or anything that's in the browser code itself.

For the former, I believe browsers aimed at more technical users can select different tradeoffs that make things more secure (e.g. qutebrowser always shows the punycode-encoded version of a URL if there's non-ASCII in it, while big browsers try to detect whether there are any confusables in it and only show it then - yet new ones are added every once in a while).

For the latter, qutebrowser has had three security bugs in almost 11 years.

qutebrowser author here, use Dodo and can confirm it's basically the qutebrowser of mail clients :)

Development is slow but not unmaintained. The author comes back every month or so to merge PRs. Reminds me I have a bunch of local changes I should upstream...

Chromium-based (QtWebEngine) would probably be more accurate. While Blink technically was WebKit at some point, it's been quite a while.

(Also you can still technically run qutebrowser with a QtWebKit from 2016, but I definitely can't recommend doing that)

qutebrowser used to use QtWebKit back in 2013, but doesn't use it anymore by default ever since its v1.0.0 release in 2017.

Ever since then, it uses QtWebEngine, which is based on Chromium. You can still use it with QtWebKit (at least until the upcoming v3.0.0 release), but that's mostly for historical reasons - I really can't recommend it, as QtWebKit is still based on a WebKit from 2016 and pretty much dead.

FWIW qutebrowser can disable JS (and also many other settings) per domain, though not on an as finegrained level as uMatrix.

However, there is this: https://gitlab.com/jgkamat/jmatrix

It's quite a hack and I have no idea where it is UI-wise, but it seems to work for some people at least.

See https://www.reddit.com/r/qutebrowser/comments/tpuqj5/qutebro... - it seems to be, unfortunately.

See https://www.reddit.com/r/qutebrowser/comments/tpuqj5/qutebro... - it seems to be, unfortunately.

Qutebrowser would become my daily driver whenever they implement extension support.

If you're thinking of WebExtensions (i.e. Chrome/Firefox/... extensions), that's unlikely to happen without Qt implementing support for it - see the FAQ in https://github.com/qutebrowser/qutebrowser/issues/30 for details.

They recently secured some EU funding, so there could be a lot of developments soon.

You must be thinking of a different project - though qutebrowser is donation-funded, and I just finished a big chunk of work at the university I'm employed at yesterday. Now I won't do anything there anymore until July or so, so there should be a lot of development in the next couple of months anyways!

FWIW you can donate (via my GitHub Sponsors profile), I'd rather not force people to pay for it, though ;)

One thing I would perhaps consider is having more "proper" releases for macOS and Windows (with things like code signing, automatic updates, etc. - perhaps even via the Windows and macOS stores) for a small one-time fee. But that's mainly because supporting those platforms properly costs me additional money (and additional time).

Fun fact, I've been asked by a VPN company if I'd ship their (somewhat proprietary) VPN stuff with qutebrowser.

The guy who contacted me didn't understand "if you won't offer a SOCKS or HTTP proxy, even if I wanted to, it's not possible".

Naturally I would be anything but comfortable with such a "partnership" (the only thing I'm exploring is getting money from search engines for qutebrowser users' searches).

Nevermind that it'd also be a bad idea from a monitary perspective, given that I'd probably lose more in donations that I'd gain from such a thing.

Hehe, yeah, I sometimes show up in random places when people mention qutebrowser thanks to https://f5bot.com/ :)

Thanks for the nice words, much appreciated too!

Well, thanks for the heads-up, I suppose ;)

https://github.com/qutebrowser/qutebrowser/commit/c022893a76...

Hey, I remember that nickname!

Yeah, for smaller projects with only a handful of people behind them, WebKit (via WebKitGTK) or Chromium (via QtWebEngine, Electron, Chromium Embedded Framework) are pretty much the only choices there are. The only exception maybe being Pale Moon.

For browsers which are based directly on the Chromium codebase without being supported by Google, there are definitely many more resources needed - I don't see a particular reason why those couldn't be based on Firefox either. From what I see in QtWebEngine, keeping up with Chromium isn't exactly easy - IIRC they said they need about a person-month to catch up with a new Chromium release, usually with millions of changed lines.

I was hoping for Servo to fill that embedding usecase gap, but it looks like that's been mostly abandoned by Mozilla nowadays. My only other hope is GeckoView: https://mozilla.github.io/geckoview/ - I know at least the people behind Tridactyl would love to see it ported to x86_64: https://tridactyl.xyz/ideas/#port-geckoview-to-x86_64

<3