Bug 482041

SUMMARY
***
kscreenlocker_greet will not allow further unlock attempts when wrong password is entered even once. One has to kill the process and unlock the session from text TTY. When the correct password is entered on the first try, no issue is observed. When the wrong password is entered, the black "dots" that indicate typed characters don't disappear from the input field. The reveal button works, showing the typed characters but even after ensuring the correct password is entered, the screen is not unlocked. Moreover, when moving the currsor to second monitor, another empty input and background wallpaper appears, as in the new greeter has been started (ps output confirms that two instances of the greeter are present at the time), and I can type the password there but even correct one doesn't unlock the screen. I have this behavrior since plasma (probably before) 5.26.x, now on the 6.0 it is the same. Also no indication about wrong password is displayed.
***


STEPS TO REPRODUCE
1. lock the screen
2. type wrong password and submit
3. type correct password and submit

OBSERVED RESULT
kscreenlocker_greet does not show any indication about entering the wrong password and does not clean input field.
another process of kscreenlocker_greet is started along the original one. User is unable to unlock the screen using neither process/input and has to kill the locker process from text tty and do loginctl unlock-session manually.

EXPECTED RESULT
upon entering invalid password, some indication is presented to the user and user can try again after some grace period, and if typing correct password, the screen will be unlocked without the need to change to the tty and kill the process by hand.


SOFTWARE/OS VERSIONS
Windows: n/a
macOS: n/a
Linux/KDE Plasma: nixOs 24.05 (unstable branch)
(available in About System)
KDE Plasma Version: 5.26.1-6.0.0
KDE Frameworks Version:   5.26.1-6.0.0
Qt Version: 5.x.x-6.6.2

ADDITIONAL INFORMATION
I didn't write down the Qt version on plasma5 and didn't write down the first plasma5 version where thsi was occuring for me. It might have been before 5.26 but this is the first one I've written down. Today I switched to plasma6 thanks to the availability in nixOs and the behavior is identical.

In the journal I see only something like this currently on plasma6:
Feb 29 14:35:56 nixos kscreenlocker_greet[7863]: pam_warn(kde-fingerprint:auth): function=[pam_sm_authenticate] flags=0 service=[kde-fingerprint] terminal=[<unknown>] user=[<REDACTED>] ruser=[<unknown>] rhost=[<unknown>]
Feb 29 14:35:56 nixos kscreenlocker_greet[7863]: pam_warn(kde-smartcard:auth): function=[pam_sm_authenticate] flags=0 service=[kde-smartcard] terminal=[<unknown>] user=[<REDACTED>] ruser=[<unknown>] rhost=[<unknown>]
Feb 29 14:35:58 nixos unix_chkpwd[7927]: password check failed for user (<REDACTED>)
Feb 29 14:35:58 nixos kscreenlocker_greet[7863]: pam_unix(kde:auth): authentication failure; logname=<REDACTED> uid=1000 euid=1000 tty= ruser= rhost=  user=<REDACTED>
Feb 29 14:35:58 nixos kscreenlocker_greet[7863]: pam_kwallet5(kde:auth): pam_kwallet5: pam_sm_authenticate
Feb 29 14:35:58 nixos kscreenlocker_greet[7863]: pam_kwallet5(kde:auth): pam_kwallet5: we were already executed
Feb 29 14:35:58 nixos unix_chkpwd[7928]: password check failed for user (<REDACTED>)
Feb 29 14:35:58 nixos kscreenlocker_greet[7863]: pam_krb5(kde:auth): authentication failure; logname=<REDACTED> uid=1000 euid=1000 tty= ruser= rhost=
Feb 29 14:35:58 nixos kscreenlocker_greet[7929]: pam_ccreds: launching helper binary
Feb 29 14:35:58 nixos kscreenlocker_greet[7929]: pam_ccreds: helper binary is not available
Feb 29 14:35:58 nixos kscreenlocker_greet[7929]: QObject::killTimer: Timers cannot be stopped from another thread
Feb 29 14:35:58 nixos kscreenlocker_greet[7929]: QObject::~QObject: Timers cannot be stopped from another thread