Bug 455494

Summary: Clicking an item in an unfocused window requires two clicks, one to focus the window and the other for the action
Product: [Applications] systemsettings Reporter: indecisiveautomator
Component: generalAssignee: Plasma Bugs List <plasma-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: ahiemstra, nate, xaver.hugl
Priority: NOR Keywords: regression, wayland-only
Version First Reported In: 5.25.0   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:
Attachments: Video showing the problem

Description indecisiveautomator 2022-06-17 15:28:38 UTC
SUMMARY
This does not apply for every window, but for some windows such as System Settings, if it's unfocused, clicking on an item in the System Settings such as one of the buttons or menu items requires two clicks. The first click focuses the window and the second click is needed to perform the action. So when clicking on the "Appearance"  option in the unfocused System Settings window, the first click focuses the window and you have to click again to actually open the "Appearance" menu. This even applies to things like the scrollbar, which are particularly jarring.

This does not apply for all applications however. Some such as Dolphin and System Settings work fine. However a number of KDE apps exhibit this behaviour (System Settings, Info Center, Discover). Xwayland apps also seem to consistently exhibit this, a number of games running under Xwayland will need an extra click.


STEPS TO REPRODUCE
1. Open System Settings (I am using this purely as an example because I know it happens with this one, but it is not exclusive to System Settings)
2. Unfocus the window
3. Refocus it by attempting to click on an item in the System Settings
4. The window will regain focus but the option you clicked will not do anything until you click again.

OBSERVED RESULT
Some unfocused KDE applications need a second click to perform an action and their action is not performed in the same click that gives them focus. 


EXPECTED RESULT
Clicking on a window should focus it and perform the action the mouse was clicking on.


SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 5.18.3-zen1-1-zen (64bit)
KDE Plasma Version: 5.25.0
KDE Frameworks Version: 5.95.0
Qt Version: 5.15.4

ADDITIONAL INFORMATION
Have not tried X11
Comment 1 Nate Graham 2022-06-17 19:07:41 UTC
Cannot reproduce, how bizarre.

Is this a regression from Plasma 5.24?
Comment 2 indecisiveautomator 2022-06-17 19:18:15 UTC
I am almost positive. I don't really want to roll back and find out to be brutally honest, but I might have a machine somewhere with Plasma 5.24.X. I'll see if I can dig one out and find out in the next few days.

I recorded a video to show the behaviour, I'll see if I can figure out how to add an attachment. The recording doesn't show the mouse cursor as OBS doesn't show the mouse cursor in Plasma 5.25 Wayland anymore but that's an OBS bug I think.
Comment 3 indecisiveautomator 2022-06-17 19:18:23 UTC
Created attachment 149867 [details]
Video showing the problem

Mouse cursor did not show up due to a bug with the recording software (OBS), but a mouse was used.
Comment 4 indecisiveautomator 2022-06-21 15:07:37 UTC
As of 5.25.1 this is fixed in every KDE application I experienced the bug in *except* System Settings. The behaviour is identical still in System Settings.
Comment 5 indecisiveautomator 2022-06-30 04:27:41 UTC
Same behaviour in Plasma 5.25.2
Comment 6 indecisiveautomator 2022-08-05 02:44:24 UTC
This behaviour is not present on SteamOS 3.3, which uses Plasma X11 5.23.5, Qt 5.15.2, and Frameworks 5.90.0.
Comment 7 indecisiveautomator 2022-09-15 22:14:03 UTC
Can still reproduce with 5.26 Beta. Again only seems to affect System Settings-related windows such as Info Center, and the various separate windows such as Mouse options, Display options, etc.
Comment 8 Vlad Zahorodnii 2022-09-16 06:54:58 UTC
I can reproduce it in system settings, but not other apps, e.g. dolphin
Comment 9 Vlad Zahorodnii 2022-09-16 07:01:35 UTC
I added some qDebugs in QtWayland QPA and they are printed as expected, i.e. kwin sends pointer button events to system settings but there seems to be a problem somewhere in systemsettings.
Comment 10 Arjen Hiemstra 2022-09-19 14:49:44 UTC
So I did some digging and it seems this is a bug in QQuickWidget. When clicking, the item underneath the mouse gets a press event correctly, but then never gets a release event, so it doesn't register an actual click. Printing some debugging information from C++, the release event is passed to the QQuickWidget but then isn't handled. Unfortunately the event handling in QQuickWidget is pretty complex so I don't know where things end in there.
Comment 11 Nate Graham 2025-09-22 04:30:24 UTC
This doesn't seem to be a problem anymore in Plasma 6; marking as fixed.