Bug 183496 - screensaver (blank) - screen contents are exposed for a short time before unlocking
Summary: screensaver (blank) - screen contents are exposed for a short time before unl...
Status: RESOLVED DUPLICATE of bug 291078
Alias: None
Product: kscreensaver
Classification: Miscellaneous
Component: general (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: kscreensaver bugs tracking
URL:
Keywords:
: 214432 226395 255051 258015 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-02-07 00:24 UTC by Unknown
Modified: 2015-01-23 12:56 UTC (History)
19 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Desktop shown under unlock window (116.19 KB, image/jpeg)
2009-12-01 17:18 UTC, Bartosz Kwitniewski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Unknown 2009-02-07 00:24:38 UTC
Version:            (using KDE 4.2.0)
OS:                Linux
Installed from:    Ubuntu Packages

I am not sure whether this is a bug in the screensaver or the unlock screen modeule.
It looks like a little bit of a security issue though.

I have a blank screen saver selected. After the session is locked (Ctrl+Alt+L), the screen goes blank, that is fine.
But when I try to move the mouse or type some keys, there is a short gap between the time the mouse/key activity and the appearance of the unlock window. In between that gap, the whole screen (including the contents and any open windows) are shown for a very short while. I think, this should not happen at all.
Could you please fix the same?

Thanks a lot...
Comment 1 Michael Kreitzer 2009-04-21 21:22:20 UTC
This happens for me in kde 4.2.2 no matter the screen saver selection. It does seem to be specific to compositing being turned on for me.
Comment 2 Dario Andres 2009-05-31 03:48:44 UTC
This could be related to bug 179924. Thanks
Comment 3 Michael Kreitzer 2009-05-31 08:33:34 UTC
Hmm, I'm not sure I see the relation. Do you mind elaborating a little? 179924 seems to refer to popups or other always on top type windows covering the screensaver.

This bug is referring to the entire desktop being visible for a split second when activating the unlock dialog (via activity e.g. moving the mouse or hitting a keyboard key) right before the dialog shows.

Usually, I see the screensaver running. I move my mouse, and the entire desktop appears very briefly, then the screen turns black and the unlock diaglog appears over the black screen. Several seconds later (if you do not immediately unlock) the screensaver appears again under the unlock dialog. So ignoring the unlock dialog itself and paying attention to whats behind it the order of events is:

1) screensaver merrily going about its business
 - mouse moved -
2) desktp displayed for a split second (bad part)
3) blank screen for a few seconds
3) screensaver comes back

The ideal situation would be no change whatsoever. The unlock dialog would just appear on top of the screensaver without interruption.

I hope that made it more clear and not less so.
Comment 4 Oswald Buddenhagen 2009-05-31 10:08:30 UTC
i don't suppose you have "allow widgets on screen saver" enabled?
Comment 5 Michael Kreitzer 2009-06-01 01:49:38 UTC
I do not
Comment 6 Bartosz Kwitniewski 2009-11-27 14:46:57 UTC
Same problem here with KDE 4.3.3. Sometimes whole desktop becomes visible under unlock dialog and does not disappear (it is not clickable however), sometimes only wallpaper is visible. I alway use "show the desktop" before locking screen because of this bug. If I remember correctly it was present in KDE 3.5.x too.
Comment 7 Bartosz Kwitniewski 2009-11-27 15:34:55 UTC
The thing that is visible for a fraction of a second is probably root window. I have wallpaper set on root window with 'feh --bg-scale "file.jpg"' for conky pseudo-transparency and when I change it to something else then it is displayed, not wallpaper from plasma.

I was able to reproduce "whole desktop visible under unlock dialog" but this bug was only present for about 10 seconds after locking screen, so it is not that bad. I was unable to see any running aplications after about 10 seconds - only that root window. Put Your system under load (start one instance of glxgears for every CPU core) to reproduce.
Comment 8 Bartosz Kwitniewski 2009-12-01 17:18:24 UTC
Created attachment 38746 [details]
Desktop shown under unlock window

Today I have locked a screen with alt+control+l and returned 5 minutes later. I have moved my mouse and whole desktop appeared under unlock window as seen on this "screenshot". Desktop was static - conky window and clock didn't update and I was unable to perform any action on the desktop. As long as I have been moving my mouse/writing something on keybord, the desktop was visible. After pressing "cancel" the screen went blank and desktop didn't appear under unlock window anymore.

System: Arch Linux 64 bit, KDE 4.3.3
Settings:
- Screenserver: Blank Screen
- Start automatically after 4 min
- Require password to stop after 10 seconds

Please vote on this bug if You are affected. Sorry for fragmented comments.
Comment 9 Michael Kreitzer 2009-12-01 21:12:36 UTC
What you described is a different symptom from the original bug report and what I experience, and it may be another bug altogether worthy of its own report.

The symptom the original reporter and I experience is a brief sub second flicker of the desktop between input and the unlock dialog appearing.  It is very quick, but a digital camera shooting video would be able to capture a frame or two of the desktop contents during the brief period the desktop is visible.
Comment 10 Bartosz Kwitniewski 2009-12-01 23:59:47 UTC
You are right, "between input and the unlock dialog appearing" for fraction of a second I can see only root window (wallpaper), not window contents. And the other bug is bug #162178 so I will move there. :}
Comment 11 Tim Richardson 2010-01-07 23:09:33 UTC
sidux users are seeing this as well, so I'm going to follow this bug. I think it's a security/privacy risk.
Comment 12 Tim Richardson 2010-01-07 23:11:36 UTC
I should say that "sidux" means Debian sid, KDE 4.3.4
Comment 13 Oswald Buddenhagen 2010-02-15 00:44:26 UTC
*** Bug 214432 has been marked as a duplicate of this bug. ***
Comment 14 Oswald Buddenhagen 2010-04-02 09:57:10 UTC
possibly related to bug 162178, though the timing is different.
Comment 15 Thomas Lübking 2010-04-02 20:16:49 UTC
regarding the original bug report:

this is due to the un/redirection (the screensaver runs as FS window, thus the content is "unredirected" what basically means that compositing is turned off for that window and it's painted diretctly onto the screen to save cpu cycles, pretty helpful for games or videos)

whenever another window pops up and is stacked above the FS window it's re-redirected (basically to paint the shadows onto it ;-) what causes
a) flicker (there're some reports)
b) this bug

you can turn unredirection off by adding

UnredirectFullscreen=true

to ~/.kde[4]/config/share/kwinrc, [Compositing] group, but that will have a performance impact for FS windows (depending on the TextureFromPixmap support of your GPU/driver)

i suggest (for performance and security reasons) to suspend compositing before running the screenlocker and (in case) resume it when the the screen gets unlocked
Comment 16 Oswald Buddenhagen 2010-04-03 12:27:48 UTC
there seems to be no cross-wm way to suspend compositing.
kwin only has a global compositing toggle function, which is prone to at least two race conditions (one is two applications simultaneously trying to change the state, the other is one application exiting and re-enabling compositing while the other one is still running).
the proper solution would be adding a window manager hint and having the compositing disabled as long as any such window is mapped.

the *real* proper solution would be of course fixing the underlying problem (bug 177495). or rather, working it around at a lower level. would it be technically possible to make the re-redirection seem atomic by having the window both mapped and composited for a moment rather than neither of the two? composite a screenshot of the current mapping before removing it or something like that.
Comment 17 Martin Flöser 2010-04-03 12:49:01 UTC
another possible solution is to not unredirect screensavers. That would be fine for the cases of a black screensaver, but would have performance impact on OpenGL screensavers. Of course fixing the flicker bug would be better. I tried to investigate it some time ago (before 4.2), but obviously I failed.

Btw. I am not sure if the issue is only triggered by the unredirection. I have unredirection disabled and nevertheless see sometimes on wakeup notifications above the screensaver for a very short period of time, but I think there is another bug report for that....
Comment 18 Decha 2010-04-05 13:44:44 UTC
Are we talking about opengl compositing? Bc I have it disabled and still experience the issue.
Comment 19 Thomas Lübking 2010-04-05 15:45:11 UTC
which issue? the original one (interim "flicker" visibility) or the one from comments #7/#8 (which should be a different bug)
Comment 20 Decha 2010-04-05 18:58:57 UTC
Read initial comment and #7/#8 few times but can't spot the difference.

I sometimes see desktop contents when my screen is locked.
Comment 21 Thomas Lübking 2010-04-05 20:30:12 UTC
the original report is about the desktop showing up for a very short moment when the screensaver gets re-redirected as it looses the "fullscreen on top" state

#7 and esp. #8 are apparently about the desktop appearing and not going away (unless esc is pressed) what's either a bug in kwin, kscreensaver or X11 / the gpu driver

you actually cannot suffer from the re-redirection wink-of-an-eye thing if you turned compositing off (as w/o compositing there's nothing to un- and later re-redirect)
Comment 22 Decha 2010-04-06 12:53:47 UTC
Thanks for clarifying. I will update the bug as soon as I see the issue again. Actually I haven't seen it for a while now...
Comment 23 Aaron J. Seigo 2010-09-07 07:41:09 UTC
*** Bug 226395 has been marked as a duplicate of this bug. ***
Comment 24 Oswald Buddenhagen 2010-10-23 23:50:32 UTC
*** Bug 255051 has been marked as a duplicate of this bug. ***
Comment 25 Caleb Cushing 2010-10-24 00:49:40 UTC
I sure do wish this security bug would get fixed soon.
Comment 26 Joerg 2010-11-27 00:27:34 UTC
(In reply to comment #25)
> I sure do wish this security bug would get fixed soon.

Well its almost 2 years now it seems.
Comment 27 Holly 2012-08-17 08:09:01 UTC
I'm seeing symptoms of bug 249417, which has been closed as a duplicate of this one.  Sometimes when I lock my screen, the entire desktop is visible, but not able to be interacted with.  I don't think the system was under heavy load (firefox, kopete, dolphin, and sublime-text, load average from top < 1).

Arch Linux, kernel Linux host 3.4.7-1-ARCH #1 SMP PREEMPT Sun Jul 29 22:02:56 CEST 2012 x86_64 GNU/Linux
KDE 4.9.0
Comment 28 Peter Wu 2012-10-12 17:19:03 UTC
KDE 4.9.2 is still affected (Arch Linux)
4.8.5-0ubuntu0.1 is also affected (Kubuntu)

All screensavers from kdeartwork are also affected. (Asciiquarium, OpenGL screensavers, Polygons, ...).

The Polygons screensaver is also a bit weird. When you try to unlock, a password dialog will appear. If you cancel that, the polygons screensaver continues, but without clearing the screen. (bug or feature?).
Comment 29 Mathias 2013-01-04 11:56:15 UTC
KDE 4.9.3 still affected here by the shorty-visible-desktop-before-passwd-dialogue-bug (only if desktop effects are active)
since 4.8 even the worse symptom occures from time to time on my box (=desktop visible all the time while the dialogue asks for the password, though no desktop interaction possible)
Comment 30 Martin Flöser 2013-01-04 13:14:57 UTC
new implementation in 4.10
Comment 31 Thomas Lübking 2013-01-18 20:31:12 UTC
OP is dupe also all "screensaver exposes desktop" issues should be resolved in 4.10

*** This bug has been marked as a duplicate of bug 291078 ***
Comment 32 Martin Flöser 2015-01-23 12:56:43 UTC
*** Bug 258015 has been marked as a duplicate of this bug. ***