Chromium starts without BTI on. Normally you should be able to get binaries like this working when you remove the BTI assembly in the offending compiled binary/library with something like:
https://src.fedoraproject.org/rpms/webkitgtk/c/fac6852e5695051ade276ed08835d7baa487bf32
as seen in webgtk, although upstream projects should actually fix the underlying issue causing BTI to trigger.
teohhanhui and Stephen Gallagher have seen this. They should be available to contact here:
https://matrix.to/#/#asahi:fedoraproject.org
https://bugs.chromium.org/p/chromium/issues/detail?id=1422204
This needs to be fixed in QtWebEngine for Qt5 and Qt6 too.
cc: @jgrulich
@jgrulich @ngompa do you know someone who can (or has in the past) reproduced these failures in QtWebEngine for Qt5 and Qt6 ?
QtWebEngine is literally bundled Chromium wrapped with a Qt API. It has all the same defects as Chromium. So it will have the same problems. We already had to port other 16K page size fixes to QtWebEngine in the past.
This 100% was not the question though, is there someone who can reproduce these failures for QtWebEngine is the question, I don't push things without testing.
You could ask Asahi Lina to check by using Falkon.
Ah very good, I didn't even know Falkon was a browser until today
That's a good idea
I was kinda hoping we would only propagate the "s/-mbranch-protection=standard /-mbranch-protection=pac-ret /" fix to places that are completely unusable, because it is a workaround and I want at least a little incentive to fix BTI related issues properly upstream, without completely destroying user experience. webkitgtk was one of those places, this was going to ruin user experience as everyday things like wifi login portals for Gnome were depending on that I'm pretty sure.
QtWebEngine is used for a similar purpose in KDE Plasma, but there are also browsers like Angelfish; Falkon; and Otter Browser that use it.