Holding Enter key (for example while handling keyboard) queues large number of unlock attempts

[hramrach]

Each unlock attempt takes quite a while, and with many queued the screen effectively cannot be unlocked for a long time.

There is an option to ignore empty passwords which would likely be a workaround if it is known that the password cannot be empty.

However, there are situations in which it is desirable to support both empty password and locking. For example, when building a live medium it is desirable to build it with an empty password so that users do not have to always ask around how to log in, and at the same time support securely locking the system if the user sets a password after the system is booted.

A solution would be to ignore input typed until the verification attempt finishes, or to special-case empty password, and ignore it once it fails to unlock the system. The latter can be prone to problems if the password is only one factor, and other factor is configured in PAM.

[emersion]

We used to block while verifying a password, and this has been deemed as an undesirable feature: in case of a typo in the password, users want to start typing the correct one right away.

We could however make it so only a single password verification can be queued up at a time.

[hramrach]

Why the arbitrary delay, though?

Shouldn't that be introduced by PAM if desired by system policy?

That said, this problem would likely surface even if the delay would be introduced by PAM but the solution might need to be different then.

[emersion]

The delay is not swaylock's doing. It's the default PAM configuration.

[hramrach]

Indeed, there is a delay with other screen lockers as well. It just does not look so awkward when there is actual dialog (that only appears after the delay), and typing blindly is not the norm. The graphics in swaylock does not show the amount of text entered, and is not even displayed the whole time until the screen is unlocked or the unlock fails.