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).
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.
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.
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 ¯\_(ツ)_/¯
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].
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.
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...
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.
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...