Bug 508074 - Password entry field hidden after returning from sleep
Summary: Password entry field hidden after returning from sleep
Status: RESOLVED INTENTIONAL
Alias: None
Product: plasmashell
Classification: Plasma
Component: Screen locking (other bugs)
Version First Reported In: 6.4.3
Platform: Arch Linux Linux
: NOR normal
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-08-10 05:34 UTC by Florian Ruechel
Modified: 2025-08-12 16:39 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Florian Ruechel 2025-08-10 05:34:58 UTC
SUMMARY

Since upgrading kscreenlocker to 6.4.3 (I think!), I noticed that unlocking after suspend didn't immediately show the password field when I start typing. Pressing return or moving my mouse makes the field show up. Entering the full password works, then pressing enter shows the password entry field. Pressing it again unlocks the screen.

I have a multi-monitor setup and this is happening on my main monitor. If I move the mouse to the secondary display and then select Sleep from the menu there, then, on resume, it works as expected: Once I start typing the first letter the input field appears. I only need to press enter once.

One difference between the two displays is that the main display (the one with the problem) takes quite a while to return from its own standby. The secondary display shows the lock screen already for a few seconds before the main display starts showing anything.

I also noticed a few warnings show up in the logs:
Aug 10 14:27:46 kscreenlocker_greet[1010987]: qt.qpa.wayland: Could not create EGL surface (EGL error 0x3003)
Aug 10 14:27:46 kscreenlocker_greet[1010987]: qt.qpa.wayland: Could not create EGL surface (EGL error 0x3003)
Aug 10 14:27:46 kscreenlocker_greet[1010987]: Failed to write to the pipe: Transport endpoint is not connected.

I tried downgrading to 6.4.2 to see if it fixes the issue, but I don't know how to test the downgrade without a wholesale reboot and just downgrading the package didn't seem to resolve the issue.

Simply locking the screen (Meta+L) does not cause this issue.


STEPS TO REPRODUCE
1. Sleep/Suspend
2. Resume
3. Start typing password
4. Press Enter

OBSERVED RESULT
The display does not change its content as you type, showing no input fields (as if you hadn't started typing at all). Once Enter is pressed, the input field appears with the password fully typed in (so it was receiving the input).


EXPECTED RESULT
On pressing the first key, the password field should appear and start showing the characters as you type.


SOFTWARE/OS VERSIONS
Operating System: Arch Linux
KDE Plasma Version: 6.4.4
KDE Frameworks Version: 6.17.0
Qt Version: 6.9.1
Kernel Version: 6.15.9-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 3600 6-Core Processor
Memory: 32 GiB of RAM (31.2 GiB usable)
Graphics Processor: NVIDIA GeForce RTX 3070
Nvidia Driver Version: nvidia 575.64.05-4

ADDITIONAL INFORMATION
Please let me know how I can best provide more information. If my guess is right that my monitor is too slow to wake up, then this might be hard to reproduce for someone with different hardware.
Comment 1 Nate Graham 2025-08-11 20:12:52 UTC
This is actually the expected UX. It was broken for a while and always showed the UI without any interaction. But we fixed that recently, and now what you're experiencing is the system as we designed it. :) 

So almost literally, "it's a feature not a bug!"
Comment 2 Florian Ruechel 2025-08-11 23:09:07 UTC
Hi Nate,

Thank you for taking a look at this issue. I appreciate I might be misunderstanding you when you say "always showed the UI without any interaction", does typing a password not count as interaction? Why does it behave as I'd expect (i.e. the first key press or mouse movement shows the field) on one display, but not the other (where it only shows on enter press or mouse movement, but not typing the password)?

I totally understand that you wouldn't want to show the password field until the user does *something*, but typing the password seems like the kind of interaction that should show the field, right?

Cheers,
Flozza
Comment 3 Florian Ruechel 2025-08-12 09:39:30 UTC
I should also add: If I lock the screen, both displays behave exactly as I'd expect: If I start to type, on the first key I hit, it shows the password field.
Comment 4 Nate Graham 2025-08-12 16:39:01 UTC
The intent is as follows:

1. The lock screen only shows the wallpaper and clock by default.
2. When there's any interaction, the interactive UI elements appear as well
3. If you have multiple screens, the the interactive UI elements only appear on the screen you interacted with (using the pointer, or because it had keyboard focus)
4. If you have multiple screens and move the pointer or keyboard focus between screens, the interactive UI elements disappear on the screens without the pointer or keyboard focus