Bug 407473 - Don't disable password field for a few seconds after entering the wrong password
Summary: Don't disable password field for a few seconds after entering the wrong password
Status: CONFIRMED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Theme - Breeze (show other bugs)
Version: 5.27.80
Platform: Arch Linux Linux
: NOR wishlist
Target Milestone: 1.0
Assignee: visual-design
URL:
Keywords: junior-jobs
: 477179 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-05-12 21:25 UTC by Siddhartha
Modified: 2024-02-27 12:28 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Siddhartha 2019-05-12 21:25:56 UTC
Currently, the password input in the login/lock screen gets disabled for a timeout period after entering a wrong password. This is all good, but the behaviour can be slightly improved I think.

Instead of disabling both the input field and the login button/action, just disable the login action, so that the user can continue to edit/retype the password while waiting for the timeout to expire. This way the user can save on some of the waiting time. Especially, by the time the user is done retyping, the timeout would have expired and the user can proceed to the login action.

Apologies if there is already a way to do this easily or already been reported. 

SOFTWARE/OS VERSIONS
Operating System: Arch Linux 
KDE Plasma Version: 5.15.5
KDE Frameworks Version: 5.57.0
Qt Version: 5.12.3
Comment 2 Siddhartha 2019-05-13 16:41:12 UTC
Thanks Nate! So I did this and the text input doesn't get blocked anymore.

```
diff --git a/lookandfeel/contents/lockscreen/MainBlock.qml b/lookandfeel/contents/lockscreen/MainBlock.qml
index 97e7e943..529ccea3 100644
--- a/lookandfeel/contents/lockscreen/MainBlock.qml
+++ b/lookandfeel/contents/lockscreen/MainBlock.qml
@@ -59,7 +59,6 @@ SessionManagementScreen {
         focus: true
         echoMode: TextInput.Password
         inputMethodHints: Qt.ImhHiddenText | Qt.ImhSensitiveData | Qt.ImhNoAutoUppercase | Qt.ImhNoPredictiveText
-        enabled: !authenticator.graceLocked
         revealPasswordButtonShown: true
 
         onAccepted: {
@@ -93,6 +92,7 @@ SessionManagementScreen {
     PlasmaComponents.Button {
         id: loginButton
         Layout.fillWidth: true
+        enabled: !authenticator.graceLocked
 
         text: i18nd("plasma_lookandfeel_org.kde.lookandfeel", "Unlock")
         onClicked: startLogin()
```

I'm not sure what to change on line 88 that you linked. I guess another event should replace "onClearPassword", maybe loginButton.onsubmit but I couldn't get it to work yet.
Comment 3 Siddhartha 2019-05-13 17:02:05 UTC
I figured out one way to do this, and opened a RR at https://phabricator.kde.org/D21192. Please take a look and see if this makes sense. Thanks!
Comment 4 Nate Graham 2019-05-13 17:05:32 UTC
Good for you! I'll take a look and review the patch.
Comment 5 fanzhuyifan 2023-11-18 16:56:55 UTC
*** Bug 477179 has been marked as a duplicate of this bug. ***
Comment 6 Jeroen 2023-11-18 21:26:12 UTC
My experience of this bug (from #477179):

Upon entering a wrong password the system shows "Login failed" or "Unlocking failed", whereby the password field is locked for about 4 seconds. I don't need 4 seconds to realise what this simple message means, it's quite obvious I made a mistake so I want to retry immediately. 

Note that the system behaves slightly different when providing a wrong password on initial logon or at unlocking:
- A wrong password at initial logon results in a locked password field for 4 seconds, after which the message "Login failed" is shown.
- A wrong password at unlocking results directly in a message "Unlocking failed", after which the password field is locked for 4 seconds.

The preferred solution to this is to show either the "Login failed" or "Unlocking failed" message directly (which could be faded away after a few seconds if the user takes no action), and NOT to lock the password field so the user can try again immediately. 

An alternative would be the Windows 10 approach: upon entering the wrong password a message is shown with an OK button; it gives perfect feedback of what went wrong and by hitting Enter you can try again immediately.
Comment 7 Jeroen 2023-11-18 21:28:11 UTC
So what happened 4 years after the commit for a possible solution?