| Summary: | App launched via a desktop icon opens its own desktop file | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-kio | Reporter: | tagwerk19 |
| Component: | general | Assignee: | David Faure <faure> |
| Status: | RESOLVED FIXED | ||
| Severity: | critical | CC: | bugseforuns, fabian, jjm, kdelibs-bugs, kfm-devel, lbeltrame |
| Priority: | NOR | ||
| Version: | git master | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/frameworks/kio/commit/84e9372f4fa2636f57dc456ac2fa2be271d6a7ec | Version Fixed In: | |
| Sentry Crash Report: | |||
| Attachments: |
Patch to fix
Add autotest |
||
I can confirm this issue on neon unstable. If "When opening an executable file:" is set to "Run Script" in "Confirmations" tab of Dolphin settings, dozens of instances are launched when I open Dolphin via its icon on desktop. Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.18.80 KDE Frameworks Version: 5.71.0 Qt Version: 5.14.2 *** Bug 421404 has been marked as a duplicate of this bug. *** AFAICT, the URL should not be passed by the startService invocation here: https://cgit.kde.org/kio.git/tree/src/gui/openurljob.cpp#n578 Might need a second parameter or just be inlined without that assignment. Also happens if a desktop file is launched from the Quick Launch applet (in plasma-addons). Can also be reproduced from the command line, so suspect that the bug is really in KIO. Test case: create a minimal desktop file [Desktop Entry] Exec=ls Name=test Terminal=false Type=Application and launch it with 'kioclient5 exec testfile.desktop'. The expected result would be that the current directory is listed, which happens with a KF5 5.69.0 installation. With a current KF5/Plasma installation the desktop file itself is listed. Created attachment 128389 [details]
Patch to fix
This patch fixes the problem for me with kioclient5, Dolphin, Plasma desktop or Plasma quick launch. However, I don't know whether it covers all use cases. Please test if possible, and if it works then I will submit it for review.
(In reply to Jonathan Marten from comment #5) > Created attachment 128389 [details] > Patch to fix That's what I thought on first glance as well, but clearing m_url there is probably not a good idea, it might be used later. I'm currently working on an autotest for this. Hopefully it is the right thing to do, because if running a desktop file then m_url has already been "consumed" to find the desktop file and it shouldn't be passed to the application. After this has been done in runUrlWithMimeType() it and all its callers return immediately anyway, so m_url should not be needed any more. Created attachment 128392 [details] Add autotest (In reply to Jonathan Marten from comment #7) > Hopefully it is the right thing to do, because if running a desktop file > then m_url has already been "consumed" to find the desktop file and it > shouldn't be passed to the application. After this has been done in > runUrlWithMimeType() it and all its callers return immediately anyway, so > m_url should not be needed any more. Technically it's possible that some other method of job which uses m_url is called after starting and some changes in the future might not expect that m_url is empty at that point. IMO changing startService to take a url list is cleaner. (In reply to Fabian Vogt from comment #6) > I'm currently working on an autotest for this. Patch attached. Seems possible that
https://old.reddit.com/r/kde/comments/gieqil/recent_updates_seem_to_have_broken_run_in_terminal/
is related...
A "Link to Application" running a command "bash say-hello.sh" with advanced options "Run in terminal" set works in Neon (Frameworks 5.69.0), fails with an:
Unknown error code 100
Could not find the program 'konsole'
error in Neon Testing (Frameworks 5.71.0)
Regarding comment #9: This seems to be a different bug, in KIO::DesktopExecParser. If the command is to be run in a terminal, then the full terminal executable path needs to be resolved so that the "realExecutable" test in KProcessRunner::KProcessRunner() does not fail. Problem as in comment #9 is bug 421374. Git commit 84e9372f4fa2636f57dc456ac2fa2be271d6a7ec by Fabian Vogt. Committed on 17/05/2020 at 09:44. Pushed by fvogt into branch 'master'. Fix URL being passed as argument when launching a .desktop file Summary: When a .desktop file is executed directly, it doesn't receive a parameter. Test Plan: Test passes, applications open normally again. Reviewers: dfaure, marten Reviewed By: dfaure Subscribers: kde-frameworks-devel Tags: #frameworks Differential Revision: https://phabricator.kde.org/D29800 M +16 -5 autotests/openurljobtest.cpp M +2 -0 autotests/openurljobtest.h M +8 -4 src/gui/openurljob.cpp https://invent.kde.org/frameworks/kio/commit/84e9372f4fa2636f57dc456ac2fa2be271d6a7ec All OK now in Neon Testing...
Plasma: 5.18.90
Frameworks: 5.71.0
Qt: 5.14.2
|
SUMMARY: If click on an application shortcut created on the desktop it appears that the application is opened with the name of the whatever.desktop file as an argument. STEPS TO REPRODUCE: Create a desktop shortcut (for example by right clicking on the application in the launch menu and selecting 'Add to Desktop') For Dolphin, this creates a "org.kde.dolphin.desktop" file in the Desktop folder Click on the newly created icon. OBSERVED RESULTS: Dolphin opens in a Desktop/org.kde.dolphin.desktop/ "folder" and prompts "What do you want to do with this executable file" EXPECTED RESULTS: Dolphin opens in the Home folder. SOFTWARE/OS VERSIONS: Dolphin 20.04.0 from Neon Testing KDE Plasma 5.18.5 KDE Frameworks 5.71.0 Qt 5.14.2 ADDITIONAL INFORMATION: Probably not a Dolphin bug, not sure where to file it though; as per discussion under Bug 421329, launching Kate via its icon on desktop, opens its own .desktop file This behaviour has changed since Neon (Plasma 5.18.4, Framework 5.69.0, QT 5.14.1)