437364 2021-05-19 14:11:20 +0000 krunner shortcuts stopped working (upgrade to plasma-5.21.90) 2023-07-21 07:16:58 +0000 1 1 4 Plasma krunner general 5.25.4 Other Linux RESOLVED FIXED regression VHI normal --- 1 rdieter alexander.lohnau 6yearold a.samirh78 alexander.lohnau andy-kde bugs.kde.org fabian gene kde kde m.kurz nate plasma-bugs-null ricardo samjnaa sampingu02 svckd thunderbirdtr vkrevs https://invent.kde.org/plasma/plasma-workspace/commit/42b1039ed32c62e1d1750135cc5509caea6fe6b8 5.22.1 0 oldest_to_newest 2034029 0 rdieter 2021-05-19 14:11:20 +0000 After upgrading to plasma-5.21.90, all krunner shortcuts stopped working. Some users report seeing duplicates in systemsettings, and removing the dups fixes the issue... I'll try that and report back. 2034030 1 rdieter 2021-05-19 14:17:35 +0000 Confirmed, I saw 2 entries in systemsettings->shortcuts for krunner, one with an icon one without I deleted the one without, and reset defaults for the other, and things work again. Fwiw, here's the diff of my ~/.config/kglobalshortcutsrc before and after the change: --- kglobalshortcutsrc.BAK 2021-05-19 09:13:52.814201471 -0500 +++ kglobalshortcutsrc 2021-05-19 09:15:32.288743607 -0500 @@ -62,11 +62,6 @@ next_active_tab=none,none,Next Active Tab toggle_mainwindow_visibility=none,none,Show/Hide Konversation -[krunner.desktop] -RunClipboard=Alt+Shift+F2,Alt+Shift+F2,Run command on clipboard contents -_k_friendly_name=KRunner -_launch=Alt+Space\tAlt+F2\tSearch,Alt+Space\tAlt+F2\tSearch,KRunner - [ksmserver] Halt Without Confirmation=none,none,Halt Without Confirmation Lock Session=Meta+L\tCtrl+Alt+L\tScreensaver,Meta+L\tCtrl+Alt+L\tScreensaver,Lock Session @@ -238,9 +233,9 @@ _launch=Meta+E,Meta+E,Dolphin [org.kde.krunner.desktop] -RunClipboard=,Alt+Shift+F2,Run command on clipboard contents +RunClipboard=Alt+Shift+F2,Alt+Shift+F2,Run command on clipboard contents _k_friendly_name=KRunner -_launch=\t\t,Alt+Space\tAlt+F2\tSearch,KRunner +_launch=Alt+F2\tAlt+Space\tSearch,Alt+Space\tAlt+F2\tSearch,KRunner [org.kde.plasma.emojier.desktop] _k_friendly_name=Emoji Selector 2034031 2 rdieter 2021-05-19 14:23:15 +0000 I suspect part of this was due to krunner.desktop being renamed to org.kde.krunner.desktop... in this commit ? https://invent.kde.org/plasma/plasma-workspace/-/commit/10d647c47a0d0cf14727679a0638a4055908c107 2034042 3 kde 2021-05-19 15:17:17 +0000 There is an update script that should fix this https://invent.kde.org/plasma/plasma-workspace/-/blob/master/krunner/update/krunnerglobalshortcuts.cpp Do you have an entry like [krunnerglobalshortcuts.upd] ctime=1621407975 done=5.17KRunnerGlobalShortcuts,5.22KRunnerGlobalShortcuts mtime=1621393778 in .config/kconf_udpaterc and is /usr/share/kconf_update/krunnerglobalshortcuts.upd on your system? 2034053 4 rdieter 2021-05-19 15:36:19 +0000 ~/.config/kconf_udpaterc contains: [krunnerglobalshortcuts.upd] ctime=1621260782 mtime=1620912182 $ cat /usr/share/kconf_update/krunnerglobalshortcuts.upd Version=5 Id=5.22KRunnerGlobalShortcuts Script=krunnerglobalshortcuts 2034254 5 kde 2021-05-20 06:37:43 +0000 That means the update ẃas not run. Could you provide the times of creation and when krunnerglobalshortcuts.upd was last modified? 2034257 6 kde 2021-05-20 07:17:21 +0000 (In reply to David Redondo from comment #5) > That means the update ẃas not run. Could you provide the times of creation > and when krunnerglobalshortcuts.upd was last modified? I think at least, not sure why we have the times but not the "done" entry tbh. What happens if you run kconf_update --debug /usr/share/kconf_update/krunnerglobalshortcuts.upd kconf_update should be in the libexec dir on your system in a kf5 subfolder 2034442 7 nate 2021-05-20 18:35:38 +0000 FWIW I can reproduce this in the Wayland session but not the X11 session. $ cat /usr/share/kconf_update/krunnerglobalshortcuts.upd Version=5 Id=5.17KRunnerGlobalShortcuts Script=krunnerglobalshortcuts $ grep "krunnerglobalshortcuts.upd" -A 3 ~/.config/kconf_updaterc 156:[krunnerglobalshortcuts.upd] 157-ctime=1621259590 158-done=5.17KRunnerGlobalShortcuts,5.22KRunnerGlobalShortcuts 159-mtime=1620132570 2034537 8 kde 2021-05-21 06:50:01 +0000 (In reply to Nate Graham from comment #7) > FWIW I can reproduce this in the Wayland session but not the X11 session. This should make absolutely no difference. > $ cat /usr/share/kconf_update/krunnerglobalshortcuts.upd > Version=5 > Id=5.17KRunnerGlobalShortcuts > Script=krunnerglobalshortcuts This file is out of date but you probably have a newer one in your prefix? > $ grep "krunnerglobalshortcuts.upd" -A 3 ~/.config/kconf_updaterc > 156:[krunnerglobalshortcuts.upd] > 157-ctime=1621259590 > 158-done=5.17KRunnerGlobalShortcuts,5.22KRunnerGlobalShortcuts > 159-mtime=1620132570 Shows the update script run from your 2034654 9 nate 2021-05-21 13:56:15 +0000 Ah yeah, oops. cat ~/kde/usr/share/kconf_update/krunnerglobalshortcuts.upd Version=5 Id=5.22KRunnerGlobalShortcuts Script=krunnerglobalshortcuts 2034692 10 nate 2021-05-21 15:24:22 +0000 Hmm, now they are working for me again. I guess it's not this. 2038719 11 fabian 2021-06-08 20:55:38 +0000 openQA sees a similar issue (X11. Wayland upgrades not tested): https://openqa.opensuse.org/tests/1774482#step/updates_packagekit_kde/1 The journal shows "No desktop file found for service krunner.desktop", so this is most likely related to this migration. Restarting kglobalaccel5 helped. Does the upgrade script maybe not apply to an already running kglobalaccel5? 2038721 12 nate 2021-06-08 21:00:44 +0000 Urgh 2038879 13 kde 2021-06-09 07:27:58 +0000 >oes the upgrade script maybe not apply to an already running kglobalaccel5 It needs kglobalaccel5 running, we are instructing it do the changes insted of changing the config file under its feet. What I find interesting that I saw no "Disabling desktop file" https://invent.kde.org/frameworks/kglobalaccel/-/blob/master/src/runtime/kserviceactioncomponent.cpp#L133 in the log which we should hit when we call KGlobalAccel::self()->cleanComponent (or do we not see debugs in openqa configuration?) Which I thought maybe KGlobalAccel::isComponentActive(oldDesktopFile) is maybe false if the file is not longer present but I could confirm that to be not the case. 2038881 14 kde 2021-06-09 07:40:37 +0000 A manual test: - move /usr/share/kglobalaccel/org.kde.krunner.desktop to /usr/share/kglobalaccel/krunner.desktop - qdbus org.kde.kglobalaccel /component/org_kde_krunner_desktop org.kde.kglobalaccel.Component.cleanUp (should return true) - restart kglobalaccel5 We are now in the initial situation when you are running plasma 5.21 - undo the move from the first step, to simulate the update to 5.22 - run [...]/kconf_update_bin/krunnerglobalshortcuts (kded should have run this in case of the upgrade) For me this transfers the shortcuts to the new correct org.kde.krunner.desktop component 2038914 15 kde 2021-06-09 10:23:33 +0000 (In reply to David Redondo from comment #14) > For me this transfers the shortcuts to the new correct > org.kde.krunner.desktop component but do not work indeed... They are marked as inactive when the QActions are destroyed 2038940 16 kde 2021-06-09 11:51:37 +0000 Fix for them being set to inactive https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/921 2039020 17 nate 2021-06-09 15:46:01 +0000 Git commit 6502f798fe64bd31f043fe2f273587e166ffcb52 by Nate Graham, on behalf of David Redondo. Committed on 09/06/2021 at 15:40. Pushed by ngraham into branch 'master'. krunnerglobalshortcuts: Prevent actions from becoming inactive If a QAction is destroyed, KGlobalAccel will automaticaly set it to inactive. To prevent this put them on the heap and intentionally leak them as it did before. M +13 -11 krunner/update/krunnerglobalshortcuts.cpp https://invent.kde.org/plasma/plasma-workspace/commit/6502f798fe64bd31f043fe2f273587e166ffcb52 2039021 18 nate 2021-06-09 15:46:58 +0000 Git commit 42b1039ed32c62e1d1750135cc5509caea6fe6b8 by Nate Graham, on behalf of David Redondo. Committed on 09/06/2021 at 15:46. Pushed by ngraham into branch 'Plasma/5.22'. krunnerglobalshortcuts: Prevent actions from becoming inactive If a QAction is destroyed, KGlobalAccel will automaticaly set it to inactive. To prevent this put them on the heap and intentionally leak them as it did before. (cherry picked from commit 6502f798fe64bd31f043fe2f273587e166ffcb52) M +13 -11 krunner/update/krunnerglobalshortcuts.cpp https://invent.kde.org/plasma/plasma-workspace/commit/42b1039ed32c62e1d1750135cc5509caea6fe6b8 2039035 19 nate 2021-06-09 16:15:43 +0000 Should be fully fixed with that. Please re-open if your KRunner shortcuts are still broken after upgrading to Plasma 5.22.1 and rebooting. Don't forget the reboot. :) 2042503 20 nate 2021-06-20 13:28:45 +0000 *** Bug 413368 has been marked as a duplicate of this bug. *** 2043079 21 rdieter 2021-06-22 20:53:14 +0000 Heads up, we have at least one downstream user reporting this issue persists with plasma-5.22.1, https://bugzilla.redhat.com/show_bug.cgi?id=1974589 2043099 22 ricardo 2021-06-23 01:09:28 +0000 FWIW, I had this issue after upgrading to Plasma 5.22.0 and Gear 21.04.2. A couple of day later I upgraded to Frameworks 5.83 and the problem was solved, so I didn't need to upgrade to Plasma 5.22.1 My O.S. is Slackware64 current (a.k.a. 15.0 beta). 2043118 23 fabian 2021-06-23 06:23:54 +0000 (In reply to Rex Dieter from comment #21) > Heads up, we have at least one downstream user reporting this issue persists > with plasma-5.22.1, > > https://bugzilla.redhat.com/show_bug.cgi?id=1974589 At least openQA and my manual testing hasn't seen any issues with upgrades from 5.12, 5.18 and 5.21.5 anymore, so I don't think it's broken in general. Maybe there's some edge case with certain configs. Can you get kglobalshortcutsrc from the reporter? 2056708 24 rdieter 2021-08-27 14:49:21 +0000 Users are still reporting as unfixed, reopened. I'll direct them here to provide additional feedback, thanks. 2068278 25 nate 2021-10-13 19:32:20 +0000 No users have shown up to provide feedback. :( Given that it doesn't seem to be widely reproducible, without additional information, we won't be able to investigate further. 2068781 26 gim6626 2021-10-15 13:24:12 +0000 Sorry if it is the wrong place, but I've just upgraded to Kubuntu 21.10 from 21.04 and faced this bug. Plasma 4:5.22.5-0ubuntu1. Found 2 Krunner entries in keyboard shortcuts, one disabled and other with expected keys, reassigned - everything works now, but I still think that something is wrong with installation scripts and it should not be so, because this bug is not very easy to Google. 2068782 27 rdieter 2021-10-15 13:28:03 +0000 Still unresolved, just had a user report seeing this today in chat 2068783 28 nate 2021-10-15 13:30:38 +0000 Any ideas, Alexander or David? 2068787 29 rdieter 2021-10-15 13:39:34 +0000 I'll try to come up with reproducibility steps, iirc, it's not that hard to trigger this. 2068808 30 gene 2021-10-15 14:54:48 +0000 I am having this issue on Fedora 34. Shortcuts shows that both alt+space and alt+f2 should open krunner but they do not. 2070039 31 kde 2021-10-19 07:21:33 +0000 I have no idea since manual set up and OpenQa both worked. 5.22 is also EOL, so people who would be affected by this would be upgrading form 5.21 to 5.23 or later, not sure how common 2070406 32 gene 2021-10-20 01:46:51 +0000 (In reply to David Redondo from comment #31) > I have no idea since manual set up and OpenQa both worked. > 5.22 is also EOL, so people who would be affected by this would be > upgrading form 5.21 to 5.23 or later, not sure how common It looks like Fedora 34 is using 5.22.5 as of today. I can't speak to what is eol and what's not, but it seems that if even Fedora's current distro is impacted by this it is still relevant since very few users will be running something newer than that. 2072330 33 bugs.kde.org 2021-10-26 08:18:25 +0000 Broken in Kubuntu backports too Two krunner entries in system settings, both missing icons. Removed, but can't re add. It's very broken. Operating System: Kubuntu 21.10 KDE Plasma Version: 5.23.1 KDE Frameworks Version: 5.87.0 Qt Version: 5.15.2 Kernel Version: 5.13.0-20-generic (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i5-3230M CPU @ 2.60GHz Memory: 7.7 GiB of RAM Graphics Processor: Mesa DRI Intel® HD Graphics 4000 2072331 34 bugs.kde.org 2021-10-26 08:21:47 +0000 Work around is to add a manual custom shortcut, with the alt+space etc mappings, that just runs /usr/bin/krunner Not sure how something so simple and unchanged since forever gets busted. 2082629 35 svckd 2021-12-04 14:23:11 +0000 I upgraded to Fedora 34 recently and following the same steps mentioned in Comment 1, made KRunner shortcuts work again. I remember being affected by Bug 413368 in Fedora 31. 2095916 36 kde 2022-01-20 16:43:26 +0000 5.22 is outdated any fix now won't help anything 2146280 37 fabian 2022-08-17 13:59:16 +0000 For some reason this now started to fail in openQA tests which upgrade from 5.8/5.12/5.18 (Leap 42.x/15.x) -> 5.24 (Tumbleweed). First, kglobalacceld crashes and after the automatic restart the situation is as outlined in this report: Two entries in kglobalshortcutsrc which don't work. At least in openQA this looks like it's reproducible. Unfortunately I wasn't able to get a backtrace, but it seems to be heap corruption ("unaligned fastbin chunk detected"). The crash is not reproducible manually at least. This matches the arrival of Frameworks 5.97 in Tumbleweed. I can't tell how much 5.97.0 actually caused this or just exposed it more... CC Ahmad, who did the majority of changes in kglobalaccel 5.97. 2146296 38 fabian 2022-08-17 14:43:35 +0000 (In reply to Fabian Vogt from comment #37) > For some reason this now started to fail in openQA tests which upgrade from > 5.8/5.12/5.18 (Leap 42.x/15.x) -> 5.24 (Tumbleweed). First, kglobalacceld > crashes and after the automatic restart the situation is as outlined in this > report: Two entries in kglobalshortcutsrc which don't work. At least in > openQA this looks like it's reproducible. Unfortunately I wasn't able to get > a backtrace, but it seems to be heap corruption ("unaligned fastbin chunk > detected"). The crash is not reproducible manually at least. > > This matches the arrival of Frameworks 5.97 in Tumbleweed. I can't tell how > much 5.97.0 actually caused this or just exposed it more... > > CC Ahmad, who did the majority of changes in kglobalaccel 5.97. It's actually fairly simple: kglobalacceld crashes when the kconf_update binary runs. With valgrind, the cause is obvious: void GlobalShortcutsRegistry::writeSettings() const { const auto &lst = GlobalShortcutsRegistry::self()->allMainComponents(); for (const KdeDGlobalAccel::Component *component : lst) { KConfigGroup configGroup(&_config, component->uniqueName()); if (component->allShortcuts().isEmpty()) { configGroup.deleteGroup(); delete component; } else { component->writeSettings(configGroup); } } _config.sync(); } That method destroys the component, but leaves it in the m_components vector of the shortcuts registry, i.e. it generates dangling pointers. This results in all kinds of fun, in particular double-, triple- and quadruple- frees each time writeSettings is called. I think it just worked by sheer luck when QHash was still used. Reverting that commit makes the immediate valgrind complaints stop, but it still crashes at some point later due to latent memory corruption. I think this explains the not fully reproducible issues prior to 5.97 well. 2146312 39 fabian 2022-08-17 15:52:25 +0000 (In reply to Fabian Vogt from comment #38) > (In reply to Fabian Vogt from comment #37) > > For some reason this now started to fail in openQA tests which upgrade from > > 5.8/5.12/5.18 (Leap 42.x/15.x) -> 5.24 (Tumbleweed). First, kglobalacceld > > crashes and after the automatic restart the situation is as outlined in this > > report: Two entries in kglobalshortcutsrc which don't work. At least in > > openQA this looks like it's reproducible. Unfortunately I wasn't able to get > > a backtrace, but it seems to be heap corruption ("unaligned fastbin chunk > > detected"). The crash is not reproducible manually at least. > > > > This matches the arrival of Frameworks 5.97 in Tumbleweed. I can't tell how > > much 5.97.0 actually caused this or just exposed it more... > > > > CC Ahmad, who did the majority of changes in kglobalaccel 5.97. > > It's actually fairly simple: kglobalacceld crashes when the kconf_update > binary runs. With valgrind, the cause is obvious: "obvious" - ha! I wrote too soon. ~Component actually calls registry->takeComponent so it modifies m_components. The subtle addition of "&" in the QHash -> std::vector commit means that the container being iterated gets changed underneath the method. Just removing the "&" again doesn't fix the crash though, it just crashes differently, taking valgrind with it... Needs a closer look. 2146353 40 bug-janitor 2022-08-17 17:22:07 +0000 A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kglobalaccel/-/merge_requests/57 2146356 41 fabian 2022-08-17 17:25:41 +0000 (In reply to Bug Janitor Service from comment #40) > A possibly relevant merge request was started @ > https://invent.kde.org/frameworks/kglobalaccel/-/merge_requests/57 I tried it again from a clean slate and just removing the "&" fixed the issue completely, yay. Unfortunately that also means that it's unrelated to the remaining "shortcuts lost" issues and effectively I hijacked this bug report for something new... 2146380 42 bug-janitor 2022-08-17 18:31:34 +0000 A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kglobalaccel/-/merge_requests/58 2146633 43 fabian 2022-08-18 17:21:52 +0000 Git commit 7347a904f1c97db7b7f7fcf49b6bdd34701c7737 by Fabian Vogt. Committed on 17/08/2022 at 17:14. Pushed by fvogt into branch 'master'. Avoid iterating a container while it's being mutated Otherwise the iterators get invalidated and weird stuff happens. M +2 -1 src/runtime/globalshortcutsregistry.cpp https://invent.kde.org/frameworks/kglobalaccel/commit/7347a904f1c97db7b7f7fcf49b6bdd34701c7737 2148063 44 nate 2022-08-25 13:35:17 +0000 *** Bug 458268 has been marked as a duplicate of this bug. *** 2150971 45 nate 2022-09-08 04:33:42 +0000 Was that enough to fix it, or do we need something else? 2151009 46 fabian 2022-09-08 06:37:30 +0000 (In reply to Nate Graham from comment #45) > Was that enough to fix it, or do we need something else? The fix following comment 37 was for a regression in KF 5.97, so actually unrelated to the original report. I have no idea what the state of the original bug is after it was apparently not fully fixed (comment 21), I was never able to reproduce it and openQA doesn't see it either. 2151094 47 nate 2022-09-08 14:54:27 +0000 Ok, then let's close this since it seems like it's not clear that the original issue is indeed still a problem. 2178433 48 samjnaa 2022-11-28 11:21:13 +0000 My KDE keyboard switching shortcuts started malfunctioning over the past one month… Before that it was fine. I'm using Kubuntu Jammy 22.04.1 with latest updates. Any idea when I can get this fixed on my system? 2241938 49 andy-kde 2023-07-21 07:16:58 +0000 I note that there were reports that users were not reporting this issue. Reading through this bug I was able to fix my upgrade from Debian 11 to Debian 12. where the krunner shortcuts stopped working. It might be worth including a test / auto recover script and pushing it to the distros explicitly so that users with even less clue than me get an update to fix the problem. Thanks for all your great work /Andy Operating System: Debian GNU/Linux 12 KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 Kernel Version: 6.1.0-9-amd64 (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-4790 CPU @ 3.60GHz Memory: 15.6 GiB of RAM Graphics Processor: TAHITI Manufacturer: ASUS Product Name: All Series