481026 2024-02-07 18:14:10 +0000 kscreenlocker fallback theme multimonitor race condition 2025-12-13 03:46:19 +0000 1 1 4 Plasma plasmashell Screen locking 6.2.4 Other Linux RESOLVED WORKSFORME https://bugs.kde.org/show_bug.cgi?id=481027 https://bugs.kde.org/show_bug.cgi?id=433563 multiscreen NOR normal 1.0 1 benjaminflesch plasma-bugs-null fanzhuyifan kdedev kubrick nate 0 oldest_to_newest 2286986 0 benjaminflesch 2024-02-07 18:14:10 +0000 SUMMARY *** When kscreenlocker fallback theme is used in a multimonitor setup, an instance of the fallback theme is created for each monitor. When authenticator.onPromptForSecret() signal is received every single instance receives this signal and sends the content of their password field via `authenticator.respond(password.text);`. In some cases, the instance with the password textfield that's been edited by the user is sent, and in some cases the empty password fields of an fallback instance on another monitor is sent first. This creates a problem where the user types in the correct password, but the login still fails - which can lead to locking of their session (happened to me some times). *** STEPS TO REPRODUCE 1. have a multimonitor setup 2. use fallback theme 3. type in password on one of the screens, press enter 4. sometimes, login fails even though you have typed in the proper password (verify with "show password" button on the password input box) - this is the race condition 5. once the race condition is met, you need to figure out which window is processed first and/or type in your password into the password field on each monitor to unlock again OBSERVED RESULT user gets locked out even though they have proper password EXPECTED RESULT no locking out and no race conditon SOFTWARE/OS VERSIONS Linux/KDE Plasma: 5.93 ADDITIONAL INFORMATION In my theme I have fixed this issue by setting `Connections { target : authenticator; enabled: false }` for all lockscreen instances on monitors who don't have user interaction. In order to check for user interaction, I'm using a `MouseArea { hoverEnabled: true; }` and a state transition for the lockscreen root element like this: ``` states: [ State { name: "NoInput" when: !myMouseArea.containsMouse PropertyChanges { target: myAuthenticatorConnection enabled: false } }, State { name: "ReadyForInput" when: myMouseArea.containsMouse PropertyChanges { target: myAuthenticatorConnection enabled: true } } ] ``` With this `mouseArea.containsMouse` hack you can prevent the race condition, because only the "enabled" connection will receive the signal. 2286987 1 benjaminflesch 2024-02-07 18:16:37 +0000 I've experienced this race condition with fallback lockscreen today on plasma v6 RC2 on a three monitor setup, one monitor via HDMI and two via DVI over an USB-C docking station (displaylink) 2286988 2 benjaminflesch 2024-02-07 18:20:49 +0000 can't seem to trigger it in the breeze lockscreen right now 2286991 3 fanzhuyifan 2024-02-07 18:31:23 +0000 Where is the authorization triggered? It is possible to put a patch there so that it works for all themes? 2288834 4 nate 2024-02-15 03:48:24 +0000 I think Ultimately the issue here is that the input fields should be synced, but they're not. 2393775 5 kubrick 2025-01-30 10:30:54 +0000 Just checking, is this the bug where monitors go to sleep and then when waking up, displays are dark, and can be resolved by switching to a VT and back to KDE? 2470051 6 kdedev 2025-11-13 18:19:54 +0000 Thanks for the bug report. I'm sorry we weren't able to get to this yet. There have been many fixes and improvements since this was reported, and this issue may have been fixed. Can you please re-test on your system with Plasma 6.5.2 or later and let us know if you can still reproduce the problem? If you can, please set this report back to CONFIRMED. Thanks! 2473276 7 bug-janitor 2025-11-28 03:46:09 +0000 🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone! 2476598 8 bug-janitor 2025-12-13 03:46:19 +0000 🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.