SUMMARY STEPS TO REPRODUCE 1. Download telegram-desktop 2. Register telegram-desktop's desktop file, by opening the Settings and blindly typing the cheat code "registertg" (no input field focused) 3. Close Telegram Desktop 4. Run xdg-open 'tg://resolve?domain=durov' OBSERVED RESULT kio-exec terminates with error "unknown protocol tg://" EXPECTED RESULT Telegram Desktop starts with https://t.me/durov opened as chat KDE Plasma Version: 5.22.2 KDE Frameworks Version: 5.83.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION Deleting the local desktop file ~/.local/share/applications/userapp-Telegram-Desktop-HUPUW0.desktop solves the problem. HOWEVER, replacing the content of that same file with the content of the system-wide /usr/share/applications/telegramdesktop.desktop does NOT solve the problem. So it must be a bug in the way that KDE parses local desktop files. kioexec should not be used at all to download the url, it should just pass the argument to Telegram. Original issue at the telegram repo: https://github.com/telegramdesktop/tdesktop/issues/16478 Output of the above xdg-open command: command= "/usr/bin/telegram-desktop -workdir ~/.local/share/TelegramDesktop/ -- %u" args= ("/usr/bin/telegram-desktop -workdir ~/.local/share/TelegramDesktop/ -- %u", "tg://resolve?domain=durov") kf.kio.core: Protocol Class of url QUrl("tg://resolve?domain=durov") , isn't ':local', cancelling job. Copying QUrl("tg://resolve?domain=durov") to QUrl("file:///~/.cache/kioexec/krun/7009_0/unnamed") kf.kio.core: couldn't create slave: "Meldung von klauncher: Unbekanntes Protokoll „tg“.\n" If I am not mistaken, the above command and args string seem to have parsed the parameters incorrectly?
Sorry my bad, this is a bug from the Telegram side. They forgot to put the MimeType line into the local desktop file (but did not forget to put it into the systemwide desktop file). I will close this now.
Actually this is a KDE bug after all. While it is true, that the local desktop file does not contain the MimeType line, the ~/.config/mimeapps.list file contains a line, that the above mentioned local desktop file is the handler for tg:// links, which should be enough already to make it the default application. Unfortunately it seems that while kio respects that now the local desktop file is the default application, it seems to forget about the fact that the Exec line contains %u and incorrectly assumes that Telegram needs network transparency handled by kioexec.
The problem is that when the desktop file does not define the MimeType handler but the user says that the program should be the default for that handler, then kde-open5 will open the service with the respective mimetype not set, which will cause the resultingArguments() method to think that it cannot handle %u for that mimetype EVEN THOUGH the user overwrote the mimeapps.list such that the program is the default for that mimetype (currently default for some mimetype does not imply that the desktop file contains the Mimetype line for that mimetype, which is the problem here).
I am seeing this with several applications (but not with Thunderbird). Eg clicking on any link in Okular and LibreOffice among other applications triggers kioexec caching and then the cached copy of the web page is opened in Firefox. That copy often doesn't look as it should, and the actual URL is not available on the Firefox address bar. Also, there is no trace of the page or URL in the next session as the cache is apparently flushed between sessions. More details here: https://www.reddit.com/r/kde/comments/oj1gc5/kioexec_caches_web_pages_for_firefox/ Operating System: Debian GNU/Linux 11 KDE Plasma Version: 5.20.5 KDE Frameworks Version: 5.78.0 Qt Version: 5.15.2 Kernel Version: 5.10.0-8-amd64 OS Type: 64-bit
This sounds like bug 439477 which has been fixed by https://invent.kde.org/frameworks/kio/-/merge_requests/498 Could you test?
Nope, this bug has nothing to do with kopenwithdialog. The desktop file is generated and made default by Telegram Desktop itself.
It's not directly related to kopenwithdialog, it's more to do with the .desktop file Exec line not having %u or %U. Reading the report again, I see that you mentioned %u is used in the file, right?
Yes the desktop file contains %u
Related to (duplicate of?) bug 434362
*** Bug 437612 has been marked as a duplicate of this bug. ***
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kio/-/merge_requests/719
*** Bug 439623 has been marked as a duplicate of this bug. ***
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kio/-/merge_requests/720
Git commit bba0a515ba6aff35cdb66ae9b462faa1059b70e9 by Nicolas Fella. Committed on 31/01/2022 at 00:17. Pushed by nicolasfella into branch 'master'. [desktopexecparser] Consider associations from mimeapps.list to determine whether an app supports a scheme Currently we check whether an app has MimeType=x-scheme-handler/foo in its desktop file. This breaks for some apps, e.g. thunderbird handles mailto but does not always have it marked as such in its desktop file. Also it ignores manual associations in mimeapps.list Check whether the relevant app is in the list of possible handlers for that url scheme and don't use kioexec in that case Related: bug 440062 M +10 -0 src/core/desktopexecparser.cpp https://invent.kde.org/frameworks/kio/commit/bba0a515ba6aff35cdb66ae9b462faa1059b70e9
*** Bug 434362 has been marked as a duplicate of this bug. ***