Discuss.kde.org cannot be accessed by Konqueror


discuss.kde.org cannot be accessed by konqueror. It gives this message “Unfortunately, [your browser is unsupported]. Please switch to a supported browser to view rich content, log in and reply.” KDE’s web browser does not support KDE’s discuss web site. It looks like a strange situation.


Yeah, this is a known issue as Angelfish, Falkon and Konqueror use QtWebEngine and it’s stuck on an older version of Chromium.

There are workarounds for Angelfish and Falkon. If Konqueror has some sort of ad blocker it could be used there as well. See New version of Discourse dropped support for QtWebEngine 5.15 LTS - Forum - Manjaro Linux Forum

Edit: Once they are all upgraded to Qt6 this should no longer be an issue but this isn’t a quick fix.


Justin and I also talked about this on the Fediverse concerning Falkon (btw. Kudos)

You could circumvent this message by adding an adblocking rule like:

You could register, login, access and even work on your profile by this. However, you won’t be able to post anything (at least I couldn’t, the post button does nothing, all others work). So you’re mileage may vary but I’d wait for a QT6 QT Browser.

/edit: for those interested, there’s weaver-fossilhttps://code.jessemcclure.org/weaver/doc/tip/README.md

Or if you are on Arch, it’s available in the AUR.


But at lest on my side, it’s not possible to post a reply :pleading_face:

1 Like

OK, so I managed to reply from Falkon, but only by hacking around in the developer tools (in addition to using an ad blocking rule for ||discuss-cdn.kde.org/brotli_asset/browser-detect-*.js). The trick is to open the console, click on the discourse-….js link in the backtrace (not the composer.js one, editing that has no effect), commenting out the lines 2858 and 2859, then right-click, Save as… on the tab title (which does not actually open a save dialog, but puts up a warning sign that the file was not saved to the file system, but seems to be enough for the changes to be applied to the running session at least). Ewww! But this is how I have posted this message.

It would be helpful if KDE patched their Discourse to actually work out of the box on KDE browsers. It should be enough to

  1. remove || !CSS.supports || !CSS.supports("aspect-ratio: 1") (or even just || !CSS.supports("aspect-ratio: 1"), though the check for CSS.supports was added by upstream only to support that) from the browser detect script and
  2. remove that document.querySelectorAll call from composer.js.

Currently, this makes a very bad impression.


heh, nice hack! Wondering if it’s something for a greasemonkey userscript.

I searched a while but can’t find the discourse-….js on my system (at least not on my home folder).
Or what kind of (K)console is meant?

Tools / Web Inspector in Falkon, Tools / Inspect Current Page in Konqueror. (Or just use the Shift+Ctrl+I keyboard shortcut.) This has a Console tab, the JavaScript console. Depending on your distribution, you may have to install some optional QtWebEngine subpackage (e.g., qt5-qtwebengine-devtools on Fedora) to have the web inspector available.


After a few attempts, I finally got the AdBlock rule to work (hint for others: it seems that reloading the page is not enough, I had to open a link from discuss.kde.org that I had never opened in another tab, and I finally got the correct look without the “unsupported browser” error message).
So I can browse the site correctly, but indeed, no way to post anything, or even to reply to a message: you can type your message, but clicking the “Reply” button does nothing. :slightly_frowning_face:

Is there any “official” way of asking for the change you suggest to the site maintainers? This looks simple enough, and it’s indeed a bit of a shame to have KDE’s own browser(s) not working on one of their own websites…

@EricBrunel, I would also assume, the design of this webside is the source of trouble and not the Falkon or other browser.

It’s also possible to start with QTWEBENGINE_CHROMIUM_FLAGS=--enable-experimental-web-platform-features (or in case of qutebrowser, --qt-flag enable-experimental-web-platform-features; though I’ll probably make that the default soon when running with Qt 5). Then it looks like it’s supported without needing to only pretend that it is.

Unfortunately, the Reply button is still broken with that enabled.

That being said, I wouldn’t blame Discourse for this. Chromium 87 (the only version available with Qt 5) is rather old (December 2020). Unfortunately even for qutebrowser, the migration for Qt 6 is not done yet… Though if any qutebrowser user reads this, I can heavily recommend trying the git version with QUTE_QT_WRAPPER=PyQt6 set in your environment.