Allow user to edit wrong password on lockscreen while waiting for graceLocked period to end

Authored by siddharthasahu on May 13 2019, 5:01 PM.


Group Reviewers

BUG: 407473

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.

Test Plan

I applied the diff on my system by directly modifying the files in /usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/. With the patch, the input field does not get blocked anymore and I can edit the password while waiting for the graceLocked period to expire.

Diff Detail

R120 Plasma Workspace
Lint Skipped
Unit Tests Skipped
siddharthasahu created this revision.May 13 2019, 5:01 PM
Restricted Application added a project: Plasma. · View Herald TranscriptMay 13 2019, 5:01 PM
Restricted Application added a subscriber: plasma-devel. · View Herald Transcript
siddharthasahu requested review of this revision.May 13 2019, 5:01 PM
siddharthasahu edited the summary of this revision. (Show Details)May 13 2019, 5:04 PM
siddharthasahu added a reviewer: ngraham.
ngraham edited the summary of this revision. (Show Details)May 13 2019, 5:05 PM
ngraham added reviewers: Plasma, VDG.

I'm afraid your patch does not apply for me:

$ arc patch D21192
 INFO  Base commit is not in local repository; trying to fetch.
Created and checked out branch arcpatch-D21192.
Checking patch lookandfeel/contents/lockscreen/MainBlock.qml...
error: while searching for:
        focus: true
        echoMode: TextInput.Password
        inputMethodHints: Qt.ImhHiddenText | Qt.ImhSensitiveData | Qt.ImhNoAutoUppercase | Qt.ImhNoPredictiveText
        enabled: !authenticator.graceLocked
        revealPasswordButtonShown: true

        onAccepted: {

error: patch failed: lookandfeel/contents/lockscreen/MainBlock.qml:59
error: while searching for:
    PlasmaComponents.Button {
        id: loginButton
        Layout.fillWidth: true

        text: i18nd("plasma_lookandfeel_org.kde.lookandfeel", "Unlock")
        onClicked: startLogin()

error: patch failed: lookandfeel/contents/lockscreen/MainBlock.qml:93
Checking patch lookandfeel/contents/lockscreen/LockScreenUi.qml...
Hunk #1 succeeded at 40 (offset 4 lines).
Applying patch lookandfeel/contents/lockscreen/MainBlock.qml with 2 rejects...
Rejected hunk #1.
Rejected hunk #2.
Applied patch lookandfeel/contents/lockscreen/LockScreenUi.qml cleanly.

 Patch Failed! 
Usage Exception: Unable to apply patch!

Did you work against git master, or the version that was on your machine? If the latter, you need to work on git master if you're going to submit a patch that will be applied against git master. :)

siddharthasahu updated this revision to Diff 58025.EditedMay 13 2019, 5:32 PM

Update diff to master.

Sorry, I didn't remember I had switched to the 5.15 branch.

Thanks! In testing this out, I find that the impact is quite muted since the text field de-focuses itself after you press the return key. So in practice, if you realize that you typed the wrong password, you can't actually start typing immediately because the text field has lost its focus. I think it would keep to keep its focus while the button is disabled in order for this to work like you're intending.

That's correct. 2 points however:

ngraham accepted this revision.May 13 2019, 5:52 PM

Ah I see what you mean. It does look like the text field needs to become defocused for a brief moment to work around that bug. And it re-focused itself quickly while the button is still disabled. So I think this is good, thanks! Let's see what the Plasma folks have to say before we land the patch though.

This revision is now accepted and ready to land.May 13 2019, 5:52 PM

Cool! Thank you for the pointers to the correct place. It was much easier than I thought once I looked at the code.

Yeah, isn't QML just so nice to work with!?

This one was easy enough. I definitely liked the fact that I could edit the qml files directly and test it live without going through a compilation step. I especially enjoyed it after I managed to crash the lock screen with a typo but was able to fix the stuck lock screen by editing the qml file in a tty and killing the lockscreen process to make it reload. On the other hand, a compilation step here would've prevented this in the first place!

The rest of the code is still arcane magic to me though :)

I don't want SDDM and the lockscreen to have subtly different behaviours.

If one is changing, the other should too.

See similar files in sddm-theme

Oh, duh, right. Yes, please change the login screen version too.

Hi David!

Hmm, it seems the behavior is already different. I don't use sddm, but I tried it just now and found that the input field is already *not* disabled, plus, the notification that the login failed comes after the timeout. Looking at the qml code, the "Login Failed" message is displayed on the onLoginFailed signal, so it'd mean that this signal is delivered only after the grace period, which is different from the lock screen where (it appears) that the onFailed is delivered as soon as the password check fails.

I don't know where the onLoginFailed signal is coming from in sddm (or where the authenticator in lockscreen is defined for that matter). This will need help with a deeper investigation from someone who knows the components well.

Friendly ping! Since the behaviour is already different, can we merge this one and work on the SDDM part in a later PR?

filipf added a subscriber: filipf.Jun 1 2019, 2:39 PM

I agree with David, when doing these sorts of changes it's imperative they're instantly implemented in all relevant places. I checked SDDM (with our theme) and the password field is disabled when in the timeout period so we need to fix that.

Maybe this commit can help as a starting point for editing the SDDM theme: e9c72a0420c1

siddharthasahu added a comment.EditedJun 1 2019, 6:16 PM

I took another look. As I already mentioned, there seems to be a difference between how onLoginFailed signals work in both.
In the lock screen:

  • the onLoginFailed signal is delivered as soon as the password is detected to be incorrec. I use this signal to selectAll() the password text so the user can start editing.
  • The grace timeout is a separate signal onGraceLockedChanged, which is used to clear the "Login failed" message.

To summarize, the flow is: (enter password) --> (loginFailed) --[authenticator timeout expires]--> (graceLockedChanged).

On the other hand, in sddm:

  • the onLoginFailed signal is delivered only after grace timeout has expired.
  • the "Login failed" message is cleared with a qml timer.

the flow is: (enter password) --[authenticator timeout expires]--> (loginFailed) --> (notificationResetTimer).
The behaviour of sddm can only be made the same as the lock screen if the loginFailed signal is delivered independent of the authenticator timeout.

If someone can tell me how the onLoginFailed signals are generated, I can take a look to see if there is a difference in the backend timers. I'm guessing there is some C++ code handling this?

filipf added a comment.Jun 2 2019, 4:35 PM

I only worked on the visuals of the theme so I'm not 100% sure either, but there is extra dummy data that might be worth looking it, sddm.qml in particular:

@siddharthasahu would you like to continue working on this?