Component: Folder View / Desktop Containment (plasma-org.kde.plasma.folder) Version: Plasma 6.7.1 OS: Fedora 44, Wayland session Summary of the bug: On Plasma 6.7.1, typing on an empty desktop is supposed to invoke KRunner, governed by the useTypeAhead boolean under each Folder View applet's [Configuration][General] group in plasma-org.kde.plasma.desktop-appletsrc (default false). Instead, typing intermittently triggers Folder View's icon type-ahead (jump-to-matching-icon) behavior instead of opening KRunner — even though useTypeAhead=false is correctly set and persisted on disk at all times, before and after the bug occurs. Steps to reproduce: 1. Confirm baseline: on a freshly booted session, type on the empty desktop — KRunner opens correctly. 2. Single-click any desktop icon (select only, do not launch it). 3. Type on the empty desktop again. Expected result: KRunner opens, as in step 1. Actual result: Folder View's type-ahead activates instead (selection jumps to a matching icon), even though the on-disk useTypeAhead value is unchanged and still false. Additional observations: - Reproduced with multiple different icons/launchers including ones with standard well-formed .desktop files — not specific to any one file or its contents. - Reproduced on both screens independently (dual-4K setup, scale 1.75), and also when booting single-monitor (right screen only). - The bug is silent: journalctl --user -f shows no log entry at the moment the break occurs. (One log line, Final member StackingOrder is overridden in class QQmlDMAbstractItemModelData, was suspected as a signature at one point, but testing showed it only appears on actually launching an application via double-click, not on the single-click selection that triggers the bug — it is unrelated noise.) - Config on disk (~/.config/plasma-org.kde.plasma.desktop-appletsrc) was checked repeatedly during bug episodes and always shows useTypeAhead=false correctly persisted for all Folder View applets. This suggests the bug is a runtime state issue (e.g. the Folder View QML item-model delegate not correctly re-applying the config-bound property when the model/delegate is recreated on selection) rather than a config persistence issue. - Ruled out as causes: kconf_update re-firing, config file sync/permissions, krunner migration scripts, Plasma session restore mode, wallpaper slideshow timers, idle time/boot delay, KRunner itself being unresponsive (confirmed alive via qdbus org.kde.krunner /App display during an active bug episode). - No crash, coredump, or plasmashell restart coincides with any occurrence. Workaround in use: Binding a global shortcut via KWin (kwriteconfig6 --file kglobalshortcutsrc ... / System Settings → Shortcuts → Custom Shortcuts) to launch a specific application directly, bypassing KRunner and the desktop-typing path entirely. This avoids the bug but doesn't address the underlying Folder View state issue.
I can't reproduce this on Fedora's Plasma 6.7.2, on two different computers. With or without a selected file, krunner opens. Wait, is this with the Folder View desktop containment (i.e. the icons directly on the desktop), or with a Folder View widget on the desktop (I.e. the icons in a separate area of the desktop, with its own background)? Searching in krunner will only work directly on the desktop, not in a Folder View widget. In any case, this has nothing to do with Application Dashboard, changing component to Desktop Icons & Folder View widget.
I also can't reproduce the issue on KDE Linux, which has git master. Can you reproduce the issue in a new clean user account on the same computer with no customization?
To clarify my setup: I don't have icons directly on a full-screen desktop containment — I have Folder View **widgets** positioned in the corners of each screen (icons in the upper-left of each screen, plus a separate `/data1/tmp` Folder View widget in the lower-right of the right screen). Given your note that KRunner-via-typing only works on the desktop itself and not inside a Folder View widget, I initially wondered if this was just normal focus behavior (focus moving into the widget on click). I retested precisely to check: 1. Fresh boot, fully loaded: typing does nothing at all (presumably no focus yet — expected). 2. Click blank desktop space (outside any widget): typing now correctly opens KRunner. 3. Single-click inside a Folder View widget (on the widget itself, not even an icon): typing stops opening KRunner. 4. Click blank desktop space again: typing still does **not** open KRunner — instead, Folder View type-ahead activates, even on blank space, even though I'm no longer interacting with the widget at all. Step 4 is the key result: if this were normal focus-ownership (typing belongs to whatever you last clicked), returning focus to blank space in step 4 should have restored KRunner, the same as step 2. It didn't. This tells me the desktop containment itself gets stuck in type-ahead mode after any interaction with a Folder View widget, persisting even once you click away from that widget — and only clears on reboot. That's not "focus is legitimately elsewhere," it's the desktop containment's own state getting corrupted by a widget interaction. Separately: even setting root cause aside, this layout (Folder View widgets rather than a full-screen desktop containment) worked correctly on Fedora 43. There's no setting I've found to restore the old typing-to-KRunner behavior on 44/6.7.1 given this layout, which seems worth tracking as a regression regardless of what the underlying mechanism turns out to be.
(In reply to Malte from comment #3) > To clarify my setup: I don't have icons directly on a full-screen desktop > containment — I have Folder View **widgets** positioned in the corners of > each screen (icons in the upper-left of each screen, plus a separate > `/data1/tmp` Folder View widget in the lower-right of the right screen). This is the crucial bit of information. In the future, it's helpful to include such things about the setup immediately in the bug report > 4. Click blank desktop space again: typing still does **not** open KRunner — > instead, Folder View type-ahead activates, even on blank space, even though > I'm no longer interacting with the widget at all. AIUI the non-Folder View desktop is not a thing that can have active focus itself. Things on it (widgets) can have focus and it's possible that nothing has focus yet because nothing was clicked yet, but you can't give exclusive focus to the background - it's just a container. You gave to give active focus to a particular thing, not a container. This is not specific to the Folder View widget - if you place a Sticky Note on the Desktop (non-Folder) view and click into it, the cursor (and active focus) will be there, and clicking the empty desktop background will do nothing to change that. Only clicking another widget will. If this worked in the past, it's because things on it don't handle particular keys. > Separately: even setting root cause aside, this layout (Folder View widgets > rather than a full-screen desktop containment) worked correctly on Fedora > 43. That's fair, there does not seem to be a real reason not to reject the keystrokes in the Folder View widget if type-ahead find is disabled.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/3882
Wow, what a subtle bug. Well-spotted, Christoph.
Git commit 5a99a0c11bc015c7274bc5b4f365d13824b83b9f by Christoph Wolk. Committed on 15/07/2026 at 11:45. Pushed by cwo into branch 'master'. containments/desktop: respect type-ahead setting in widget The configuration for the type-ahead feature tests for inPopup (which is a misnomer for a property that tracks whether we're in a panel), as the alternative feature (krunner searching) is not applicable there. The feature implementation, however, tests for isContainment. These are not the same - a Folder View can be not inPopup (read: inPanel) and yet not be a containment, namely it can be a Folder View widget on the desktop. In this case, the user is able to set it to search with krunner, but it actually won't; it will do type-ahead (as its not a containment). Instead test for the same property in both: inPopup. This makes the krunner search work, as we'll not accept the key presses here and they get passed up to the containment. FIXED-IN: 6.7.4 M +1 -2 containments/desktop/package/contents/ui/FolderView.qml https://invent.kde.org/plasma/plasma-desktop/-/commit/5a99a0c11bc015c7274bc5b4f365d13824b83b9f