Bug 505288

Typo in the original bug submission.  It should read as follows:

OBSERVED RESULT

The screen is not unlocked after entering my password on the lock screen.

EXPECTED RESULT

The screen should be unlocked after I submit my password.

"Delay before password required"  seems relevant here indeed. Are you seeing an issue where you start typing your password before that time has elapsed, and the lock screens fails to disappear? Because that is what's supposed to happen.

(In reply to Nate Graham from comment #2)
> "Delay before password required"  seems relevant here indeed. Are you seeing
> an issue where you start typing your password before that time has elapsed,
> and the lock screens fails to disappear? Because that is what's supposed to
> happen.

Read my original bug report again please.

It's not 100% clear to me, unfortunately.

What is *supposed* to happen is that if you interact with the lock screen *in any way* before the "Delay before password required"  time has elapsed, then the lock screen will immediately disappear.

I gather this isn't happening for you. But we need to know *specifically* how it's not happening to you.

If I correctly enter my password on the screen with the password text field, I should NEVER be prohibited from unlocking the display and proceeding to my UI environment.

However, the scenario I described locks my out indefinitely.  That is, even after I correctly enter my password, the display remains on the lock screen.

(In reply to Vartan from comment #5)
> If I correctly enter my password on the screen with the password text field,
> I should NEVER be prohibited from unlocking the display and proceeding to my
> UI environment.
> 
> However, the scenario I described locks my out indefinitely.  That is, even
> after I correctly enter my password, the display remains on the lock screen.

Correction to typo:  "... locks me out indefinitely."

(In reply to Nate Graham from comment #4)
> It's not 100% clear to me, unfortunately.
> 
> 
> I gather this isn't happening for you. But we need to know *specifically*
> how it's not happening to you.

I believe I have already provided a detailed description of the scenario and what __appears__ to be a race condition.

If you still don't understand after re-reading my original comment (re-read the part about the race condition and the user entry close to the time period expiration), then provide a detailed description of just what it is that you don't understand.

This is a bug.  No system I've ever seen works this way.

We're trying to pin down exactly what the sequence of user-facing or user-input events, and timing of those events, is when you're seeing this issue. "Race condition" would be a cause - it's important to be clear about the specific symptoms first (somewhat related: https://community.kde.org/Get_Involved/Issue_Reporting#Proposing_a_solution )

The thing that sticks out to me as surprising is that you mentioned "+/-" the delay - using hypothetical numbers, are you saying that if you set a delay of 5 seconds after locking, but start typing your password at 4 seconds after locking, the screen does not automatically unlock?

If so, that seems likely to be key to the issue, as that itself is unintended behavior - the interaction of typing at 4 seconds after locking should immediately unlock your device. If it only happens within a certain time range after the delay period, but *not* before, that's helpful to know as well.

Thanks!

The two relevant settings (I think) are these:

1.  System Settings -> Screen Locking -> "Lock screen automatically"
2.  System Settings -> Screen Locking -> "Delay before password required"

I'll refer to these as settings as parameters p1 and p2, respectively.   On my system, p1 is set to 10 minutes and p2 is set to 5 seconds, but I don't believe that the values are significant.  I have experimented with various values, and I can still reproduce the bug. 

After the expiration of the period given by p1, the lock screen dialog appears.  If I type my password and hit RETURN (or the right arrow) prior to the expiration of the period given by p2, the screen remains unlocked, and I can continue with my session.

However, this does not always work correctly.  When the bug appears, I remain locked out of my session indefinitely.  I have tried waiting for several minutes to see if there is a timeout period; there is none that I've seen.

Here's the detailed scenario:
1.  The time period given my p1 expires.
2.  The lock screen dialog appears.
3.  I type my password and hit RETURN (or the right arrow) close to the expiration of the value given by p2.
4.  The lock screen remains.

Thereafter, the only way to unlock the screen is to do the following:
1.  Select "Switch User"
2.  Type my password in the text field and hit RETURN

I believe there is a race condition between:
1.  the screen locking that starts when p2 expires
2.  the screen unlocking code that executes when I enter my password

I have not looked at any code, but the race condition explanation makes sense to me intuitively.  It seems that there is no proper locking of the screen lock state -- no proper mutex locking of the state, however that's implemented.

(In reply to Vartan from comment #9)
> 3.  I type my password and hit RETURN (or the right arrow) close to the
> expiration of the value given by p2.

It sounds like if you *start* typing your password after the "Delay before password required" has already been met - using your real-life settings as an example, 7 seconds after the screen locks automatically - then input is accepted into the password field but unlocking is impossible.

If you start typing your password *before* the "Delay before password required" has already been met - using your real-life settings, say at 3 seconds after the screen locks automatically - does the lockscreen remain with input appearing in the password field, or does the lockscreen dismiss on the first keystroke?

(In reply to John Kizer from comment #10)
> (In reply to Vartan from comment #9)
> > 3.  I type my password and hit RETURN (or the right arrow) close to the
> > expiration of the value given by p2.
> 
> It sounds like if you *start* typing your password after the "Delay before
> password required" has already been met - using your real-life settings as
> an example, 7 seconds after the screen locks automatically - then input is
> accepted into the password field but unlocking is impossible.
> 
> If you start typing your password *before* the "Delay before password
> required" has already been met - using your real-life settings, say at 3
> seconds after the screen locks automatically - does the lockscreen remain
> with input appearing in the password field, or does the lockscreen dismiss
> on the first keystroke?

I can reproduce the problem via either of these scenarios:
1.  I start typing my password 'just before' p2 expires.
2.  I start typing my password 'within some short time after' p2 expires.

In other words, 'just before' and 'within a short time after' are relatively short delta time periods.  That is to say, I'm not waiting for 5 minutes after the screen has locked to type my password to unlock the screen.  Nor am I typing my password within 1 second of the time the lock screen appears (with the password entry prompt). 

The time period is not exact, obviously.  But I will say that I specifically try to achieve 1 and 2 above in order to test my theory that there is a race condition.  For instance, I specifically ran the test where I start counting as soon as the lock screen dialog appears (after expiration of p1).  I start counting "one thousand one, one thousand two, one thousand three...) and when I reach just before 5 seconds (using my settings) I start to type my password.  Doing this I can reproduce the bug a fair percentage of the time.

(In reply to John Kizer from comment #10)
> (In reply to Vartan from comment #9)
> > 3.  I type my password and hit RETURN (or the right arrow) close to the
> > expiration of the value given by p2.
> 
> It sounds like if you *start* typing your password after the "Delay before
> password required" has already been met - using your real-life settings as
> an example, 7 seconds after the screen locks automatically - then input is
> accepted into the password field but unlocking is impossible.
> 
> If you start typing your password *before* the "Delay before password
> required" has already been met - using your real-life settings, say at 3
> seconds after the screen locks automatically - does the lockscreen remain
> with input appearing in the password field, or does the lockscreen dismiss
> on the first keystroke?

Once the lock screen appears, it never disappears unless the screen unlocking is successful, which can only occur if I type the correct password and hit RETURN or click the right arrow, AND if the bug does not manifest.

So, to answer your question, the lock screen NEVER disappears after the first keystroke.

Thanks - based on the way that the diagnosis in https://bugs.kde.org/show_bug.cgi?id=500339 is going, I'm willing to bet that the condition you observed here about the "Delay before password required" time is what's triggering the situation, which then shows the same symptoms in both reports. So, I'm merging these together to help consolidate where diagnosis is happening. Thanks!

*** This bug has been marked as a duplicate of bug 500339 ***