Problem with frameworks 5.86.0 and Konqueror

[Stefano Crocco]

Hello to everyone.
I'm the current Konqueror maintainer and I need help about how to solve an 
incompatibility between the 5.86.0 version of KIO and Konqueror itself. 

After upgrading KDE frameworks from version 5.85.0 to 5.86.0 on my system, I 
noticed that whenever I entered an http(s) URL in the location bar, the page 
would be opened in a new tab, instead of the current tab like it used to (and 
should) do.

After a bit of investigation, I came to the conclusion that the cause of this 
behaviour is the change introduced to 
KIO::DesktopExecParser::hasSchemeHandler() by the commit https://
invent.kde.org/frameworks/kio/-/commit/
5fa55a2395cbfb6504e56bf71c869c8e49902e13

If I understand correctly, this commit removes the precedence previously given 
to kioslaves when there's both a kioslave and a protocol handler for the given 
URL. In Konqueror, this causes the problem I described because Konqueror 
relies in KRun::foundMimeType being called on a subclass of KRun to determine 
how to open an URL when its mimetype is initially unknown. In KIO 5.86.0 this 
doesn't happen anymore because KIO::DesktopExecParser::hasSchemeHandler 
(called from krun.cpp:460) now returns true for http(s) URLs, which causes 
KRun to directly launch the preferred application for those URLs. In my case, 
this is kfmclient_html, which is part of Konqueror itself. Depending on the 
user's settings, calling kfmclient_html could either open the URL in a new tab 
(my situation) or even in a new Konqueror window.

This problem doesn't only affect http(s) URLs: if I enter, for example, a man: 
URL, the man page isn't opened in Konqueror, as it used to, but in 
KHelpCenter, which is something which shouldn't happen at all.

Looking at the documentation and the source code for KRun I couldn't find a way 
to restore the pre-5.86.0 behaviour. Am I missing something? What would be the 
best way to solve this issue? Initially, when I hadn't yet realized that this 
issue wasn't only for http(s) URLs, I thought of handling those in a special 
way. However, given that the problem is more widespread, I don't think this 
can be done.

Thanks in advance

Stefano