Created attachment 195837 [details] Annotated network manager, with the fields causing the bug visibile (See screenshot: if the System Tray network manager is not the "Networks widget", please edit this bug) DESCRIPTION The networks manager in the system tray has a search field at the top. When you click "Connect" on a network in the list, it opens a text field to input the password and focus switches to that password field. At this point, clicking on the search field does not focus it: Ctrl + F shortcut does focus the search field, and seems to be the only way. Typing after clicking on the search field still enters text in the network password field, because focus never left. OBSERVED RESULT Focus remains in the network password field EXPECTED RESULT Focus switches to the search field, when clicked SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.7.4 KDE Frameworks Version: 6.29.0 Qt Version: 6.11.2 ADDITIONAL INFORMATION
I can reproduce this on master.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-nm/-/merge_requests/649
Git commit 2ba4a3ce55c32e432e9bf7c1fe248c56eb1b13de by Christoph Wolk. Committed on 09/09/2026 at 07:25. Pushed by cwo into branch 'master'. applet: don't prevent moving focus from password to search field 6c46b8c2fc0017f5afa4e02340dbadb3730226c9 introduced a workaround for ExpandableListItem moving focus on hover, which interrupted the user while entering passwords if they accidentally moved the pointer. To do this, it forced activeFocus on the password field if it loses activeFocus while still having focus and if the new activeFocusItem's focusReason is falsy (which it is when hovering over a ConnectionItem, because it's an ExpandableListItem, which is not a Control and does not have a focusReason, so it's undefined). This however breaks clicking the search field, because MouseFocusReason is 0 and so falsy as well, while focusing it with Ctrl+F still works as that sets ShortcutFocusReason. Instead, explicitly check whether we have a focusReason (and if we do, whether it's OtherFocusReason, which is what ListView sets when the currentItem is changed if it were a control). This avoids the misleading cast from enum to bool, and makes clicking the search field work again. This way of doing it remains hacky, and gives awkward UX in edge cases that are hard to fix, so we add a comment explaining this with a reminder to replace this with a better implementation when ELI is changed to allow this. FIXED-IN: 6.7.6 M +8 -1 applet/ConnectionItem.qml https://invent.kde.org/plasma/plasma-nm/-/commit/2ba4a3ce55c32e432e9bf7c1fe248c56eb1b13de
Git commit fbf2d8181f8aa7ce96d7edac70384395cce71c08 by Christoph Wolk. Committed on 09/09/2026 at 07:55. Pushed by cwo into branch 'Plasma/6.7'. applet: don't prevent moving focus from password to search field 6c46b8c2fc0017f5afa4e02340dbadb3730226c9 introduced a workaround for ExpandableListItem moving focus on hover, which interrupted the user while entering passwords if they accidentally moved the pointer. To do this, it forced activeFocus on the password field if it loses activeFocus while still having focus and if the new activeFocusItem's focusReason is falsy (which it is when hovering over a ConnectionItem, because it's an ExpandableListItem, which is not a Control and does not have a focusReason, so it's undefined). This however breaks clicking the search field, because MouseFocusReason is 0 and so falsy as well, while focusing it with Ctrl+F still works as that sets ShortcutFocusReason. Instead, explicitly check whether we have a focusReason (and if we do, whether it's OtherFocusReason, which is what ListView sets when the currentItem is changed if it were a control). This avoids the misleading cast from enum to bool, and makes clicking the search field work again. This way of doing it remains hacky, and gives awkward UX in edge cases that are hard to fix, so we add a comment explaining this with a reminder to replace this with a better implementation when ELI is changed to allow this. FIXED-IN: 6.7.6 (cherry picked from commit 2ba4a3ce55c32e432e9bf7c1fe248c56eb1b13de) Co-authored-by: Christoph Wolk <cwo.kde@posteo.net> M +8 -1 applet/ConnectionItem.qml https://invent.kde.org/plasma/plasma-nm/-/commit/fbf2d8181f8aa7ce96d7edac70384395cce71c08
Git commit eb8f4ec47d7f726e52612ab440d7a39b9a785bff by Christoph Wolk. Committed on 06/10/2026 at 13:31. Pushed by cwo into branch 'Plasma/6.6'. applet: don't prevent moving focus from password to search field 6c46b8c2fc0017f5afa4e02340dbadb3730226c9 introduced a workaround for ExpandableListItem moving focus on hover, which interrupted the user while entering passwords if they accidentally moved the pointer. To do this, it forced activeFocus on the password field if it loses activeFocus while still having focus and if the new activeFocusItem's focusReason is falsy (which it is when hovering over a ConnectionItem, because it's an ExpandableListItem, which is not a Control and does not have a focusReason, so it's undefined). This however breaks clicking the search field, because MouseFocusReason is 0 and so falsy as well, while focusing it with Ctrl+F still works as that sets ShortcutFocusReason. Instead, explicitly check whether we have a focusReason (and if we do, whether it's OtherFocusReason, which is what ListView sets when the currentItem is changed if it were a control). This avoids the misleading cast from enum to bool, and makes clicking the search field work again. This way of doing it remains hacky, and gives awkward UX in edge cases that are hard to fix, so we add a comment explaining this with a reminder to replace this with a better implementation when ELI is changed to allow this. FIXED-IN: 6.7.6 (cherry picked from commit 2ba4a3ce55c32e432e9bf7c1fe248c56eb1b13de) Co-authored-by: Christoph Wolk <cwo.kde@posteo.net> M +8 -1 applet/ConnectionItem.qml https://invent.kde.org/plasma/plasma-nm/-/commit/eb8f4ec47d7f726e52612ab440d7a39b9a785bff