Bug 439814

Summary: After suspending the contents on screen before suspend are visible for short period of time before lock screen shows up
Product: [Plasma] kscreenlocker Reporter: kornerius
Component: greeterAssignee: Plasma Bugs List <plasma-bugs>
Status: RESOLVED DUPLICATE    
Severity: major CC: bhush94, nate, onitake
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Debian testing   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description kornerius 2021-07-13 20:36:42 UTC
SUMMARY
After suspending the contents on screen before suspend are visible for short period of time before lock screen shows up

STEPS TO REPRODUCE
1. Leave anything open on the screen
2. Suspend the computer
3. Resume the computer

OBSERVED RESULT
Desktop with applications that were open before suspend are is possible to see in its entirety after resuming for short period of time before the lock screen loads. 


EXPECTED RESULT


SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Debian Testing (bullseye)
KDE Plasma Version: 5.20.5
KDE Frameworks Version: 5.78.0
Qt Version: 5.15.2

ADDITIONAL INFORMATION
Version of the lock screen had been gathered from libkscreenlocker5, it's version is 5.20.5-1
Comment 1 onitake 2021-07-17 06:14:26 UTC
I can confirm this. 

It started happening some time ago, but I don't remember when exactly. And it may not even be a Plasma issue, but a change in systemd behavior.

I suspect it's either because kscreenlocker takes too long to activate, or because it doesn't block suspension until the lock screen is up.

Is that even possible? This StackExchange answer suggests it is a wider issue with the way systemd handles suspend: https://unix.stackexchange.com/questions/643511/cinnamon-screen-stays-unlocked-1-second-after-opening-lid-suspend-resume
Blocking systemd for a fixed number of seconds could help, but it's not a robust solution. Blocking indefinitely also seems like a bad idea, because it could prevent suspend completely when a locker gets stuck.

I suppose the best fix at this point would be to always activate the locker manually before triggering a suspend.
Comment 2 Nate Graham 2021-08-03 17:00:05 UTC

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