Bugzilla – Bug 1173711
konqueror Cannot Initiate the konq Protocol, Unable to Create io-slave
Last modified: 2022-03-01 17:25:49 UTC
When konqueror is started and the selected page to show at startup is either "Show Introduction Page" "Show Blank Page" "Show My Start Page" konq.blank an error page is displayed instead at startup telling that the konq protocol cannot be initiated: ---- Error page begin ---- The requested operation could not be completed Cannot Initiate the konq Protocol Technical Reason: Unable to Create io-slave Details of the Request: URL: konq:konqueror Protocol: konq Date and Time: Saturday, July 4, 2020 9:33:03 AM CEST Additional Information: klauncher said: Unbekanntes Protokoll „konq“. Description: The io-slave which provides access to the <strong>konq</strong> protocol could not be started. This is usually due to technical reasons. Possible Causes: klauncher could not find or start the plugin which provides the protocol.This means you may have an outdated version of the plugin. ---- Error page end ---- This error happens on Tumbleweed already for some time (current snapshot 20200701) and also on Leap 15.2 GA. Workaround: ignore the error or select "Show My Bookmarks" as startup page.
Checking my logs (on Leap 15.2) messages-20200526.xz:2020-05-23T11:10:17.632254-05:00 nwr2 kded5[2801]: window match: "Error: Cannot Initiate the konq Protocol — Konqueror" :OK messages-20200526.xz:2020-05-23T11:10:17.632797-05:00 nwr2 kded5[2801]: window match: "Error: Cannot Initiate the konq Protocol — Konqueror" :OK I am not finding anything more recent. I'm pretty sure that this happens when konqueror is configured to use "webkit" but does not happen when configured to use "webengine". I haven't tried with "khtml". Yes, setting "show my bookmarks" works around this with "webkit". But that is not supported with "webengine". Personally, I can live with these inconsistencies. Note that you have to install "webenginepart" to have that choice available for konqueror.
Thanks for the hint with webengine. Yes, my konqueror is set to use "webkit". I installed webenginepart and switched to webengine: the startup page can be displayed without error. Also entering "konq:blank" and "konq:konqueror" on the address bar both successfully show a page (the same) and not an error. I interpret this that the konq - protocol is still working (supported by kio). But it seems webengine is not supporting to send the "do not track DNT header". It does not send it regardless of the related internet setting. Therefore I will stay with webkit, the error page on startup or opening a new tab is a minor problem. But if the konq protocol is still working, maybe it can also be re-enabled for the webkit mode. Or, if webkit is deprecated, webengine should learn the DNT header.
(In reply to Dirk Weber from comment #2) >> I interpret this that the konq - protocol is still working (supported by > kio). There is no konq protocol and never was. This has been newly introduced in konqueror 20.04 when the startup page was ported away from khtml. But so far support for it was only added to the webenginepart. Maybe kwebkitpart gets it as well, but that needs to be done upstream. The only openSUSE-specific thing here is that we still install kwebkitpart by default. We could change this, but that won't fix the problems and missing features with webenginepart, rather makes them more obvious.
FTR, this is the relavant commit in konqueror: https://invent.kde.org/network/konqueror/-/commit/64f94b6b78312506f34a302e3e4b79d4a97f88eb Since then, the about page is no longer shown using KHTML (which is dead since years), but rather uses the configured rendering backend that needs to intercept konq: URLs for that to work. And so far only webenginepart does.
Thanks for looking into this. That the startup or blank page can not be displayed with webkit(part) is not serious at all. It just looked like a regression to me, it seemed that something that was working before stopped working and I was worried that there could be something more serious behind it. So if there is no openSUSE specific problem (build or dependency issue) related please feel free to close this bug.
Ok, I'll close it as upstream then. If support for this gets implemented in kwebkitpart, I'll submit an update of course. So far there's only a merge request pending to show a proper error message though: https://invent.kde.org/libraries/kwebkitpart/-/merge_requests/1
*** Bug 1178125 has been marked as a duplicate of this bug. ***
In the end, the upstream solution was to always open konq: URLs (i.e. the introduction page) in webenginepart, regardless of what html renderer is configured/used. I submitted an update with that fix to Leap: https://build.opensuse.org/request/show/942216 Of course that means that webenginepart actually has to be installed (this is enforced now with a Requires in the package), and then it's also used by default for webpages, which probably is not even a bad idea though, as QtWebKit (even the "new" revived one) is really old and outdated meanwhile. But it's still possible to configure kwebkitpart as standard engine or use the View menu to switch to it as before, if you have it installed.
openSUSE-RU-2021:1634-1: An update that has one recommended fix can now be installed. Category: recommended (moderate) Bug References: 1173711 CVE References: JIRA References: Sources used: openSUSE Leap 15.2 (src): konqueror-20.04.2-lp152.2.3.1 openSUSE Backports SLE-15-SP3 (src): konqueror-20.04.2-bp153.2.5.1
openSUSE-RU-2022:0001-1: An update that has one recommended fix can now be installed. Category: recommended (moderate) Bug References: 1173711 CVE References: JIRA References: Sources used: openSUSE Backports SLE-15-SP2 (src): konqueror-20.04.2-bp152.2.4.1
openSUSE-RU-2022:0001-1: An update that has two recommended fixes can now be installed. Category: recommended (important) Bug References: 1173711,1193437 CVE References: JIRA References: Sources used: openSUSE Leap 15.3 (src): ha-cluster-bootstrap-0.5-13.3.1 openSUSE Backports SLE-15-SP2 (src): konqueror-20.04.2-bp152.2.4.1
The updates were released a while ago.