Bug 439814 - After suspending the contents on screen before suspend are visible for short period of time before lock screen shows up
Summary: After suspending the contents on screen before suspend are visible for short ...
Status: RESOLVED DUPLICATE of bug 316734
Alias: None
Product: kscreenlocker
Classification: Plasma
Component: greeter (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR major
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-07-13 20:36 UTC by kornerius
Modified: 2021-08-03 17:00 UTC (History)
3 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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 ***