https://bugs.kde.org/show_bug.cgi?id=481026
Bug ID: 481026
Summary: kscreenlocker fallback theme multimonitor race
condition
Classification: Plasma
Product: kscreenlocker
Version: 5.93.0
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: plasma-b...@kde.org
Reporter: benjaminfle...@icloud.com
Target Milestone: ---
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.
--
You are receiving this mail because:
You are watching all bug changes.
