SUMMARY This has happened multiple times and is causing grief: I lock my KDE Plasma session, walk away, come back and input my login password + hit enter while the screen is still black. The expected result is that my password was inputted for the login screen *only*. What actually occurs is that I'm logged in and the password is inputted into the application that has focus. This is incredibly problematic if the user has a chat application focused, especially one that does not allow deleting sent messages. I haven't been able to find the exact steps to reproduce yet: I'm not sure yet if the nature of the bug is technical or design (or user). It could be that: 1. Somehow the last-focused application is receiving keyboard input while locked. This is unlikely. 2. There isn't enough feedback regarding a successful login when the screen is "waking up" (restoring from a black screen). I think 2 might be the root cause: When the session is locked and the screen is dimmed/blacked out, the login password can be successfully entered *before* the screen has recovered from being blacked out. In this scenario, the user never sees the lock/login screen, and instead, their desktop is shown after the screen recovered from being black out. Maybe all that needs to be changed to address this is to decrease the time it takes for the screen to recover from being blacked out once locked. This would allow the user to see instantly that they're typing in their password into the login screen (and not an application on their desktop). Alternatively, maybe the password input text box should only be enabled when the screen is not blacked out. I'm not sure if these suggestions are flawed, but I hope they help explain the possible nature of the issue STEPS TO REPRODUCE 1. Lock the desktop 2. Let the screen automatically switch off/darken (the time this takes can be modified in System Settings >> Hardware >> Energy Saving >> Screen Energy Saving 3. Type in the session login password quickly and hit enter OBSERVED RESULT The lock screen won't be shown when the screen recovers from being blacked out. Instead, the user will be presented with their desktop. Again, if the screen instantly recovered from being blacked out, the user wouldn't have the time to enter their password before the screen recovers. Thus, they'd have visual confirmation that they are indeed entering their password on the login screen and not some application on the desktop. EXPECTED RESULT The user is presented with the lock screen confirming they are logged in (or typing their password into the password field). In any case, the user should be shown the login screen before their desktop. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora 32 KDE Plasma Version: 5.18.5 KDE Frameworks Version: KDE Frameworks 5.70.0 Qt Version: Qt 5.14.2 (built against 5.14.2) The bug's behavior is different but it could be related to: Bug 423063 ADDITIONAL INFORMATION I love KDE Plasma!!! It's my favorite desktop ever :) Sorry if I posted this bug for the wrong product/component, it's my first KDE bug. Thank you so much!
So I've been actively trying to reproduce the bug and now have learned a bit more about the nature of the bug. From what it seems, there are certain scenarios where my Plasma session's screen will turn black without actually locking the screen. Thus, when this occurs, I type in my login password and hit enter before the screen has recovered from being darkened. The issue is that my session is not locked and thus whatever application that was last focused receives the keyboard input. In my Plasma settings, I have: - Power Management >> Energy Saving >> Dim Screen after 10 min - Power Management >> Energy Saving >> Screen energy saving: switch off after 10 min - Power Management >> Energy Saving >> Suspend session is *not* enabled - Workspace Behavior >> Screen locking >> Lock screen automatically after 10 min - Workspace Behavior >> Screen locking >> Lock screen after waking from sleep enabled - Workspace Behavior >> Screen locking >> Allow unlocking without password for: immediately Ideas as to what causes the issue: - Suspend session (in power management) is not enabled. Maybe this would force the session to always lock after a period of inactivity, as per the "Lock screen after waking from sleep enabled" setting. However, ideally, I don't want to resort to suspending my session (as it'll take more time to resume using my laptop) - There is a race condition between "Dim Screen after 10 min" and "Lock screen automatically after 10 min". I don't know why dimming the screen would prevent the locking from occurring, but the fact that the screen dim's but does not lock is suspicious. - "Lock screen automatically after X min" has a bug, and does not always get triggered. For now, I'm going to set automatic screen locking after 5 minutes, to see if the bug continues. I hope this update is a bit more actionable. If further information is required just let me know :)
1. How are you locking the desktop? 2. Are you sating that the screen fails to lock when you lock it, or that it locks, but then unlocks after waking up before you've endered your password to unlock it?
(In reply to Nate Graham from comment #2) > 1. How are you locking the desktop? > 2. Are you sating that the screen fails to lock when you lock it, or that it > locks, but then unlocks after waking up before you've endered your password > to unlock it? 1. I'm letting the desktop lock itself automatically (after a period of 10 minutes of inactivty, mentioned in comment #2 2. I'm not entirely sure, it's hard to tell. I'd say the screen fails to automatically lock itself, but its being dimmed/darkened. It is possible that it's being locked then unlocked before entering my password, but there are cases where it locks successfully and appears locked when I wake it up. Thus, I believe it's failing to automatically lock after the inactivity period, in certain cases.
Can you verify that the next time you suspect it's going to happen? While the screen is off, bang on the keyboard and move the mouse to get the screen to turn on again, and then you can see if the lock screen is visible, or if it's your unlocked desktop.
(In reply to Nate Graham from comment #4) > Can you verify that the next time you suspect it's going to happen? While > the screen is off, bang on the keyboard and move the mouse to get the screen > to turn on again, and then you can see if the lock screen is visible, or if > it's your unlocked desktop. This is actually what led to my second comment. However, I'll do this again to make sure :) IIRC, moving the mouse did not wake the screen as well, but typing a key on my keyboard did - and it showed my unlocked desktop. Will keep you updated, thank you very much for the followup Nate!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!