| Summary: | Don't disable password field for a few seconds after entering the wrong password | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Siddhartha <kde> |
| Component: | Theme - Breeze | Assignee: | visual-design |
| Status: | ASSIGNED --- | ||
| Severity: | wishlist | CC: | akashsrocks1234+kde, alpenblauwtje, beavailable, bugseforuns, fanzhuyifan, liusen, nate, phoenix_87_c, plasma-bugs, redford |
| Priority: | NOR | Keywords: | junior-jobs |
| Version First Reported In: | 5.27.80 | ||
| Target Milestone: | 1.0 | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Siddhartha
2019-05-12 21:25:56 UTC
Relevant code is https://cgit.kde.org/plasma-workspace.git/tree/lookandfeel/contents/lockscreen/MainBlock.qml#n66 and https://cgit.kde.org/plasma-workspace.git/tree/lookandfeel/contents/lockscreen/MainBlock.qml#n88 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.
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! Good for you! I'll take a look and review the patch. *** Bug 477179 has been marked as a duplicate of this bug. *** 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. So what happened 4 years after the commit for a possible solution? *** Bug 488665 has been marked as a duplicate of this bug. *** *** Bug 488991 has been marked as a duplicate of this bug. *** So what happened 5 years after the commit for a possible solution? Nothing, obviously. This issue is my daily annoyance, because I have a long password and it's easy to mistype it :( I think it ideally should work like on Android or Windows: The first few incorrect tries incur no penalty, only if you retry wrong passwords multiple times the delay gets introduced and gradually increases (exponentially). Note, that this approach doesn't really worsen the security, it should even be better, because the exponentiality prevents brute-force better than the current approach with a constant delay. A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5253 A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5253 A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/2851 Tried my hand at a possible solution for this. Enabling this behaviour for the SDDM theme, also requires an extension in SDDM itself. KScreenLocker currently makes sets the PAM fail delay to 0, while SDDM doesn't. I tried making the same changes into SDDM, while avoiding breaking existing themes. MRs: Plasma-Workspace: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5253 Plasma-Desktop: https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/2851 SDDM: https://github.com/sddm/sddm/pull/2047 |