This is a feature request to add a configuration option to reject keypresses on screen locker if the password entry is not visible. DETAILS: The current behavior of the KDE screen locker is to accept input to the password field on key presses if the display is awake regardless of whether or not the field is visible. In my opinion this is bad for UX especially for some users coming from Windows (me), where pressing the "space" key or some other key on the screen locker will reveal the password field, but not input the space character. This oftentimes leads to my first attempt at typing my password being rejected. I understand that plenty of longtime KDE/Linux users don't have this problem and immediately start typing their password to log in. And I also know that pressing some Ctrl or some other modifier key will revel the password field without entering text. Force of habit is a powerful thing that leads me to pressing space every single time. I'm not proposing nor do I want to break other people's workflow, but it would be nice to at least have the option to reject the first keypress that sets the password UI visible.
Thanks for the feature request. I would reword this a little. Option to: Reject input in the password input field until after a key is pressed If we rejected all key presses at the lock screen, it would prevent it from showing the password field with the keyboard (as opposed to the mouse). There would also be users who, some for accessibility reasons, would need a way of focusing the input field with the keyboard (for instance with tab) if necessary. I'll forward this on so the maintainers can weigh in.
Thanks for the catch, I updated the title to reflect that(In reply to TraceyC from comment #1) > Thanks for the feature request. I would reword this a little. > > Option to: > Reject input in the password input field until after a key is pressed > > If we rejected all key presses at the lock screen, it would prevent it from > showing the password field with the keyboard (as opposed to the mouse). > There would also be users who, some for accessibility reasons, would need a > way of focusing the input field with the keyboard (for instance with tab) if > necessary. > > I'll forward this on so the maintainers can weigh in. Thanks for the input, I updated the title to reflect that. I'm not looking to reject all key presses on the lock screen, I would just like to not have key presses forwarded to the text box until after a key press, mouse movement, click, etc makes the password field visible. I think also clearing the password field when it becomes visible could also provide the same functionality without having to reject key presses on the lock screen.