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

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).

Servo when?

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)

It seems that they moved it since to a bigger meta issue and it's actively being worked on https://github.com/servo/servo/issues/30593. There's wider interest since it is being used in the experimental Verso browser now. There's also ongoing effort from the Qt side: https://www.kdab.com/embedding-servo-in-qt/

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

The whole ecosystem is steadily moving ahead. They'll get there eventually I'm sure.

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! :)

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

No, I’m on macOS. I think my main issue was with videos that didn’t always play correctly. Can’t remember exactly but I think either on Reddit or Twitter, it was just not reliable.

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.

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