Bug 481026 - kscreenlocker fallback theme multimonitor race condition
Summary: kscreenlocker fallback theme multimonitor race condition
Status: CONFIRMED
Alias: None
Product: kscreenlocker
Classification: Plasma
Component: general (show other bugs)
Version: 5.93.0
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords: multiscreen
Depends on:
Blocks:
 
Reported: 2024-02-07 18:14 UTC by Benjamin Flesch
Modified: 2024-02-15 03:48 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Benjamin Flesch 2024-02-07 18:14:10 UTC
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.
Comment 1 Benjamin Flesch 2024-02-07 18:16:37 UTC
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)
Comment 2 Benjamin Flesch 2024-02-07 18:20:49 UTC
can't seem to trigger it in the breeze lockscreen right now
Comment 3 fanzhuyifan 2024-02-07 18:31:23 UTC
Where is the authorization triggered? It is possible to put a patch there so that it works for all themes?
Comment 4 Nate Graham 2024-02-15 03:48:24 UTC
I think Ultimately the issue here is that the input fields should be synced, but they're not.