Version: (using KDE KDE 3.2.1) Installed from: Compiled From Sources OS: Linux If you right click the desktop and bring up a menu, kscreensaver will not start at all. As soon as you close this menu, the screensaver fuctions correctly. This also happens if you right click an icon.
*** Bug 77991 has been marked as a duplicate of this bug. ***
*** Bug 86935 has been marked as a duplicate of this bug. ***
*** Bug 124283 has been marked as a duplicate of this bug. ***
*** Bug 189668 has been marked as a duplicate of this bug. ***
*** Bug 176637 has been marked as a duplicate of this bug. ***
I can confirm the problem. For Debian Lenny (with KDE 3.5 and our e35 client) or Etch on a KDE desktop, if you keep the mouse within an open menu, the screensaver will not start. This is a security problem as the machine does not get locked if a person leaves the desk for a while. How to reproduce: Enable the screensaver with password requirement (e.g. 1min and 5 sec). Go to a menu and open it with the mouse and keep the mouse there. Just wait. Nothing happens. This works with the KDE start menu as simplified test-case.
why did you assign that to allen? even more so without ensuring that the default tracker address (which is being watched) stays in the loop?
@Oswald: Because if nobody is going to fix this, Allen will do it - so I have assigned it to him. Sorry for not keeping the list in the loop - I did not know this custom. Can you assign it to Allen and keep the list in the loop as necessary? Thanks!
would you bet that allen will fix it? ;) anyway, i think the current cc: setup is just fine.
@Oswald, yes I am pretty sure Allen will fix it - the question is only when he will do it. (Background: My company Intevation is a partner of KDAB and together we do paid work on KDE and the Kolab Client. This is a security related issue and we like to get it fixed.)
well, then i should mention that this is a rather fundamental problem. either you find a way to steal grabs (maybe the extension which controls the alt-ctrl-numpad-slash/asterisk provides that), hack around it by sending close events to popup windows, or implement the locker by opening a new x server and disabling virtual terminal switching (gdm wants to go the latter route in the middle run).
I can confirm this still happens in KDE SC 4.6.4. It's been already said but I must stress that, in my humble opinion, this is a fundamental security issue that should be given more attention.
I've upgraded severity and priority. Alvaro, thanks for testing this. (The situation changed in that I cannot promisse and work of Allen on this right now.)
*** Bug 334051 has been marked as a duplicate of this bug. ***
*** Bug 203649 has been marked as a duplicate of this bug. ***
I'm happy to announce that the upcoming Plasma 5.5 comes with a Wayland session which does no longer expose this sever issue. As the problem described in this bug reports is unfixable with X11, I consider this bug as fixed on Wayland.
*** Bug 358859 has been marked as a duplicate of this bug. ***
*** Bug 373235 has been marked as a duplicate of this bug. ***
*** Bug 439416 has been marked as a duplicate of this bug. ***