SUMMARY When I open Brave by right-clicking its desktop shortcut, choosing "Actions", then "New Window", it passes the .desktop file as an argument to the program. STEPS TO REPRODUCE 1. Open the KDE Application launcher widget and search for Brave 2. Drag the Brave app to your desktop 3. Choose the "link here" option when prompted. 4. Right click the Brave desktop icon, hover over the "Actions" menu, then select either "New Window" or "New Incognito Window". OBSERVED RESULT It opens the .desktop file in the URL bar. (/usr/share/applications/brave-browser.desktop). This makes me think that KDE is appending the .desktop file to the launch command for whatever reason. EXPECTED RESULT It shouldn't open the .desktop file in the browser. SOFTWARE/OS VERSIONS Operating System: Kubuntu 19.10 KDE Plasma Version: 5.17.5 KDE Frameworks Version: 5.66.0 Qt Version: 5.12.4 Kernel Version: 5.3.0-29-generic OS Type: 64-bit Processors: 8 × Intel® Core™ i5-9300H CPU @ 2.40GHz Memory: 7.6 GiB of RAM ADDITIONAL INFORMATION If I double click the desktop icon instead of right clicking and going into "Actions", it opens correctly.
Same thing here. Also reproducible with Firefox, Chromium and Opera browsers. Operating System: Arch Linux KDE Plasma Version: 5.18.2 KDE Frameworks Version: 5.67.0 Qt Version: 5.14.1
lol how silly
Happens when the short is launched from Dolphin too; not sure this has to to with Plasma. Moving to KIO.
Not sure if that's the same bug: Also happens with the "Application Launcher"(*): It now (as of 5.24.0) opens the .desktop file in kate, instead of launching the application :(( (*) Not the "Application Menu" in the panel, but the "Application Launcher Version pre0.1" that you can bind to root window mouse clicks in Desktop Settings->Mouse Actions
(In reply to Pit from comment #4) > Not sure if that's the same bug: Also happens with the "Application > Launcher"(*): > It now (as of 5.24.0) opens the .desktop file in kate, instead of launching > the application :(( > > (*) Not the "Application Menu" in the panel, but the "Application Launcher > Version pre0.1" that you can bind to root window mouse clicks in Desktop > Settings->Mouse Actions It's a different bug
The relevant code is at https://invent.kde.org/frameworks/kio/-/blob/master/src/widgets/kfileitemactions.cpp#L201 The problem is this: The actions menu is a list of externally supplied actions that can be performed on the file. So passing the file as argument when executing the action makes sense. The problem here is that we are operating on a desktop file, which itself contains a list of actions (e.g. "New tab"). We append these actions to the actions submenu. However, these actions are different to all the other actions in the sense that they should not be applied to the desktop file itself. Probably they should not be part of the actions submenu at all. Perhaps it could make sense to show them at the top of the menu, next to the Open/Open With action
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kio/-/merge_requests/878
Git commit 5e2dc5a18473f47f44ec93f9c23d4aae4838a77b by Nicolas Fella. Committed on 14/08/2022 at 18:34. Pushed by nicolasfella into branch 'master'. [kfileitemactions] Show desktop file actions more prominently For desktop files we currently show two kinds of actions in the "Actions" submenu: The actions defined by the desktop file itself and the externally provided file actions However, the two are conceptually different things. The latter operate on the desktop file itself, the former does not The former are also much more relevant in a folderview context This patch moves the desktop file's own actions out of the menu and up next to the "Open with" actions It also fixes executing those actions by not passing the file url as an argument M +27 -9 src/widgets/kfileitemactions.cpp https://invent.kde.org/frameworks/kio/commit/5e2dc5a18473f47f44ec93f9c23d4aae4838a77b