Bug 179924

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.

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.

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).

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.

*** Bug 183600 has been marked as a duplicate of this bug. ***

(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).

The same applies to RSIBreak application.

Aaron, it's a security sensitive bug, BTW.

It should be resolved ASAP.

*** Bug 159959 has been marked as a duplicate of this bug. ***

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.

Created attachment 32410 [details]
Proposed fix

@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 :)

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.

@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 :) )

SVN commit 946749 by gateau:

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

BUG:179924

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

SVN commit 946770 by gateau:

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

CCBUG:179924

 M  +5 -2      popupapplet.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=946770

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
CCMAIL:aurelien.gateau@canonical.com
CCBUG:179924


 M  +1 -2      popupapplet.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=951366

Here's an improved patch from Aurelian
http://bazaar.launchpad.net/~kubuntu-members/kdelibs/ubuntu/revision/46

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.

*** Bug 188408 has been marked as a duplicate of this bug. ***

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

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.

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?)

*** Bug 189987 has been marked as a duplicate of this bug. ***

SVN commit 956998 by gateau:

Do not let plasma popup appear over screensaver.

BUG: 179924


CCMAIL:aseigo@kde.org

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


WebSVN link: http://websvn.kde.org/?view=rev&revision=956998

please use CCBUG in such cases - we do not have to manually reopen the bug again and again ;-)

*** Bug 180651 has been marked as a duplicate of this bug. ***

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

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

Nevermind.

Is the case stated in bug 191278 related to this too ? Thanks

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.

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 :)

Still there in 4.4RC1

-Intel 945
-openSuSE 11.2 x86

Obviously, because no one on the kscreensaver team can fix this problem - this bug's "Product" is set incorrectly.

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.

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
xorg-server 1.6.3.901-r2

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

*** Bug 244912 has been marked as a duplicate of this bug. ***

*** Bug 248667 has been marked as a duplicate of this bug. ***

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 

http://commits.kde.org/kde-workspace/431aad6d6994695e72697fcc3299ec2cb6f0684e