Bug 179924 - Notifications still show through when the screen is locked (black) - privacy issue
Summary: Notifications still show through when the screen is locked (black) - privacy ...
Alias: None
Product: kscreensaver
Classification: Miscellaneous
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: kscreensaver bugs tracking
: 159959 180651 183600 188408 189987 244912 248667 (view as bug list)
Depends on: 158262
  Show dependency treegraph
Reported: 2009-01-07 17:52 UTC by Gregor Petrin
Modified: 2012-11-17 21:30 UTC (History)
25 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.9.0

Proposed fix (1.31 KB, patch)
2009-03-26 16:10 UTC, Aurelien Gateau

Note You need to log in before you can comment on or make changes to this bug.
Description Gregor Petrin 2009-01-07 17:52:11 UTC
Version:           KDE: 4.1.87 (KDE 4.1.87 (KDE 4.2 >= 20090101)) "release 3.1", Plasma Workspace: 0.3 (using Devel)
OS:                Linux
Installed from:    Compiled sources

When the screen is locked & black, notifications still show through. The screen was locked using the Lock/Logout plasmoid. Two examples: kmail and kopete. With kmail it is not so problematic, as it just shows the number (and directories) of new mails received. But with kopete, the received message text is displayed; what is worse, it does not seem to ever go away.. so if you leave your computer locked and go somewhere, other people can very easily read your incoming kopete messages.

I am filing this bug as a plasma bug because maybe the best idea would be to disable notifications showing altogether while the screen is locked, as a lot of notifications may contain private text? Or just specifying that there are one or more notifications waiting, but actually displaying them when the user unlocks the screen?
Comment 1 Aaron J. Seigo 2009-01-07 18:36:20 UTC
this is a bigger issue than just the notifications ... NOTHING should be allowed above the screen saver. hmmm... will talk with the kwin folk about this one.
Comment 2 Chani 2009-01-08 03:09:42 UTC
I wonder if this is related to some composite drawing issues with widgets-on-screensaver...
anyawys, the notifications-showing problem was in kde3 too - it seems like sometimes the lockprocess restacking code works and they go away fast (or at least go grey), but often something goes wrong and the screensaver binary itself appears to be drawing over the notification - as if the thing painted itself into the window the screensaver paints on. not sure what's really going on there but it makes for some odd effects.
Comment 3 Gregor Petrin 2009-01-08 09:53:00 UTC
I tested this bug some more, it is possible that this part of my original bug report is wrong: "what is worse, [the notification] does not seem to ever go away". I tried it with two computers today and the notification does go away after a few seconds, also after the first kopete message, the following ones did not appear anymore.

I'm not sure what happened yesterday that the kopete notification was not removed after those few seconds (I came back to work and it was there on my locked screen, after unlocking the computer the kopete timestamp indicated the message was sent 2 hours ago).
Comment 4 Ricardo Ferreira 2009-01-22 18:44:34 UTC
Confirming this issue. OpenSuSE KDE 4.1.96.
Notifications are drawn over screensaver and then when they disappear, a seethrough region is left there where the notification was until the screensaver redraws.

Gfx card: Mobility Radeon 9700 and driver radeon opensource.
Comment 5 Dario Andres 2009-02-08 00:37:04 UTC
*** Bug 183600 has been marked as a duplicate of this bug. ***
Comment 6 Valerio Pilo 2009-03-06 15:53:08 UTC
(In reply to comment #4)
> Notifications are drawn over screensaver and then when they disappear, a
> seethrough region is left there where the notification was until the
> screensaver redraws.
> Gfx card: Mobility Radeon 9700 and driver radeon opensource.

I have the same issue, under KDE 4.2.65 and both Qt 4.4.3 and 4.5. My gfx driver is the intel one, with compositing off (and I remember kde exposing the bug with compositing on, too).
Comment 7 Artem S. Tashkinov 2009-03-18 07:07:00 UTC
The same applies to RSIBreak application.
Comment 8 Artem S. Tashkinov 2009-03-18 07:09:36 UTC
Aaron, it's a security sensitive bug, BTW.

It should be resolved ASAP.
Comment 9 Jonathan Riddell 2009-03-25 23:32:41 UTC
*** Bug 159959 has been marked as a duplicate of this bug. ***
Comment 10 Aurelien Gateau 2009-03-26 16:09:13 UTC
Taking inspiration from KPassivePopup code, attached patch should fix the problem.

Note: patch was written for KDE 4.2.1, but seems to apply fine (with an offset) on current trunk.
Comment 11 Aurelien Gateau 2009-03-26 16:10:40 UTC
Created attachment 32410 [details]
Proposed fix
Comment 12 Aaron J. Seigo 2009-03-26 20:47:35 UTC
@Aurelien: looks fine. please commit. 

btw, note that with the volume of bug reports we get, it's sometimes (often) faster and more certain to send the patch to plasma-devel@ or post it on reviewboard.kde.org :)
Comment 13 Artem S. Tashkinov 2009-03-27 21:17:03 UTC
Has anyone tried to run Skype for Linux after applying this patch? Skype shows its own notification windows and they also appeared above the screen saver window.

As far as I understand the commit changes the way native KDE notifications are shown and not all other possible scenarios.

So, I might be wrong or this bug is not yet resolved.
Comment 14 Aurelien Gateau 2009-03-30 10:55:53 UTC
@Aaron: ok, about to commit. Will use reviewboard next time :)

@Artem: did you check if Skype popup also appears above xlock screen? If so, then it's up to Skype to fix their code (I would gladly do it, but they won't give me the source code :) )
Comment 15 Aurelien Gateau 2009-03-30 11:00:23 UTC
SVN commit 946749 by gateau:

Use Qt::Tool window flags for popups to avoid having them shown over screensaver.


I do not have a working copy of kdelibs 4.2 at the moment. Can someone backport
the fix?

 M  +5 -2      popupapplet.cpp  

WebSVN link: http://websvn.kde.org/?view=rev&revision=946749
Comment 16 Aurelien Gateau 2009-03-30 12:35:37 UTC
SVN commit 946770 by gateau:

Use Qt::Tool window flags for popups to avoid having them shown over screensaver.


 M  +5 -2      popupapplet.cpp  

WebSVN link: http://websvn.kde.org/?view=rev&revision=946770
Comment 17 Aaron J. Seigo 2009-04-09 06:18:12 UTC
SVN commit 951366 by aseigo:

revert commit#946749 as it causes way too many side effects including: widgets not getting focus (kickoff no longer puts focus on the line edit), popups not going away when clicking elsewhere ...
will need another fix for BR#179924

 M  +1 -2      popupapplet.cpp  

WebSVN link: http://websvn.kde.org/?view=rev&revision=951366
Comment 18 Jonathan Riddell 2009-04-10 01:14:54 UTC
Here's an improved patch from Aurelian
Comment 19 Oswald Buddenhagen 2009-04-11 09:52:18 UTC
hmpf - works for me:
  while :; do kdialog --passivepopup "This is a test" 5; sleep 10; done
then lock the screen.
intel gfx, no compositing (unlikely that it matters).

it's logical that the notification stays on the screen once it gets on top of the screen saver - for performance, many savers redraw only the actually changed contents. and as they don't expect strange things to happen, they don't react to regional repaint requests, either.

somebody who can reproduce the problem please paste the messages from krunner_lock (4.1) / kscreenlocker (4.2) found at/near the end of ~/.xsession-errors (provided kdm is used, otherwise you have to figure out yourself) after unlocking the screen.
Comment 20 Oswald Buddenhagen 2009-04-13 17:10:06 UTC
*** Bug 188408 has been marked as a duplicate of this bug. ***
Comment 21 Aurelien Gateau 2009-04-17 10:45:48 UTC
SVN commit 955241 by gateau:

Do not let plasma popup appear over screensaver.

BUG: 179924

 M  +13 -17    popupapplet.cpp  
 M  +1 -0      private/popupapplet_p.h  

WebSVN link: http://websvn.kde.org/?view=rev&revision=955241
Comment 22 Martin Flöser 2009-04-17 10:51:05 UTC
Sorry, but that's not really fixed. Given the duplicate bug #188408 for example. It's fixed for Plasma popups, now, but the root cause is still not fixed.
Comment 23 Artem S. Tashkinov 2009-04-17 11:08:14 UTC
I still believe that patching Plasma is not the right way to go, since this bug may appear hear and there for new Linux applications not written "properly" and given that possibility I'm still sure it's a kwin/screensaver bug (btw, no such issue existed in KDE 3.5.x - what has changed since that time?)
Comment 24 Dario Andres 2009-04-19 16:17:56 UTC
*** Bug 189987 has been marked as a duplicate of this bug. ***
Comment 25 Aurelien Gateau 2009-04-21 11:20:13 UTC
SVN commit 956998 by gateau:

Do not let plasma popup appear over screensaver.

BUG: 179924


 M  +13 -17    popupapplet.cpp  
 M  +1 -0      private/popupapplet_p.h  

WebSVN link: http://websvn.kde.org/?view=rev&revision=956998
Comment 26 Martin Flöser 2009-04-21 11:26:14 UTC
please use CCBUG in such cases - we do not have to manually reopen the bug again and again ;-)
Comment 27 Dario Andres 2009-04-25 20:35:01 UTC
*** Bug 180651 has been marked as a duplicate of this bug. ***
Comment 28 Lubos Lunak 2009-04-29 17:21:10 UTC
SVN commit 961161 by lunakl:

Simplify the restacking code.
CCBUG: 179924

 M  +18 -31    lockprocess.cc  

WebSVN link: http://websvn.kde.org/?view=rev&revision=961161
Comment 29 Lubos Lunak 2009-04-29 17:41:23 UTC
SVN commit 961177 by lunakl:

// We actually have to check the current stacking order. When an override-redirect
// window is shown or raised, it can get above the screensaver window and there's not
// much to do to prevent it (only the compositing manager can prevent that). This
// is detected by the screenlocker and handled here, but the contents of the window
// may remain visible, since some screensavers don't react to Expose events and
// don't repaint as necessary. Therefore, if a window is detected above any of the windows
// related to screenlocking, I don't see any better possibility than to completely
// erase the screenlocker window.
BUG: 179924

 M  +40 -2     lockprocess.cc  

WebSVN link: http://websvn.kde.org/?view=rev&revision=961177
Comment 30 Lubos Lunak 2009-04-29 17:44:15 UTC
Comment 31 Dario Andres 2009-05-01 19:11:52 UTC
Is the case stated in bug 191278 related to this too ? Thanks
Comment 32 Alex 2009-09-04 14:18:13 UTC
This is in KDE 4.3 still an issue. Worse, when the notification is hidden, a short time the screen-content under the notification is visible before the screen turns black again.
Comment 33 Artem S. Tashkinov 2009-09-19 17:10:49 UTC
In KDE 4.3.1 this issue persists.

I firmly believe that fixing just KDE applications will NOT fix this issue, since I have other applications which show their notifications above screensaver (e.g. audacious xosd).

So, it seems like a KWin bug for me.

Oops, I'm repeating myself :)
Comment 34 Rolf Eike Beer 2010-01-11 11:47:47 UTC
Still there in 4.4RC1

-Intel 945
-openSuSE 11.2 x86
Comment 35 Artem S. Tashkinov 2010-01-11 12:21:01 UTC
Obviously, because no one on the kscreensaver team can fix this problem - this bug's "Product" is set incorrectly.
Comment 36 Alex 2010-01-11 18:26:13 UTC
It got even worse: if you shake your mouse after the screensaver is activated, you see the plamoids of the blank screensaver but no black background but the windows below. If you click cancel on the passwort-prompt, the background gets black, as it should.
Comment 37 nick 2010-01-30 21:38:26 UTC
Another data point for you perhaps:
When watching a video in mplayer at fullscreen, the notifications still come up on top of the video.

This is with desktop effects disabled.
KDE 4.3.4
QT 4.5.3
Comment 38 Lubos Lunak 2010-06-12 12:27:25 UTC
SVN commit 1137311 by lunakl:

Try harder not to have any race conditions in the code that tries
to prevent windows showing up above the screensaver window.
I'm however getting rather confident that plasma notifications
showing above screensaver is actually an X bug.
CCBUG: 179924

 M  +113 -19   lockprocess.cc  
 M  +7 -0      lockprocess.h  

WebSVN link: http://websvn.kde.org/?view=rev&revision=1137311
Comment 39 Martin Flöser 2010-08-28 15:42:13 UTC
*** Bug 244912 has been marked as a duplicate of this bug. ***
Comment 40 Ben Gouhier 2011-05-12 06:52:08 UTC
*** Bug 248667 has been marked as a duplicate of this bug. ***
Comment 41 Martin Flöser 2012-04-22 20:14:18 UTC
The last remaining issue in this bug has probably been in the compositor: the notification got stacked *behind* the lock window (not visible) but when the notification closed the window (fade out/slide out) animation stacked the notification above the lock window (visible).

With 4.9 we fixed bug #158262 which means the notification is no longer stacked above the lock window so I am quite confident that finally this very annoying bug has been fixed.

For the record:
Git commit 431aad6d6994695e72697fcc3299ec2cb6f0684e by Martin Gräßlin. 
Committed on 09/04/2012 at 11:06.
Pushed by graesslin into branch 'master'.

Keep position in stacking order for deleted windows 

Workspace::addDeleted swaps the Client with the Deleted in the stacking order. For Unmanaged windows the Deleted is appended to the stacking order which is the same layer. 

When the deleted is closed the window is removed from the stacking order. 

The result is that a deleted window is no longer raised above all other clients. 

REVIEW: 104519 
FIXED-IN: 4.9.0 

M +1 -1 kwin/deleted.cpp 
M +0 -3 kwin/layers.cpp 
M +15 -3 kwin/workspace.cpp 
M +1 -1 kwin/workspace.h