Version: (using KDE 4.4.2) OS: Linux Installed from: Ubuntu Packages When you select the sleep from the plasma battery monitor and move the mouse up in a corner and the effect "Present all windows" is being activated, the password prompt will not be shown when you go out of sleep. A person has full access to the desktop. * How to Reproduce: 0. Make sure you have set a corner to Present all Windows 1. Press the Sleep from the battery monitor 2. Move the mouse to the corner you have set the effect to. 3. Wait for the laptop to sleep 4. Go out of sleep Now you should not be prompted for a password and have full access to the desktop
I can confirm that this bug is still present in KDE 4.6.3.
> I can confirm that this bug is still present in KDE 4.6.3. and I can promise that it will also be present in 4.6.4, 4.7.0 most likely also in 4.8.0, 4.9.0, 5.0.0 and so on. Maybe with Wayland we will be able to fix it.
A possible solution to the problem would be to listen to the screen locking attempt and disabling the effect. But I'm not sure whether there is such a signal before the screen locker tries to lock the screen and even if the timing is difficult. So this also needs adjustments in kscreenlocker to try several times to lock the screen. As that needs new functionality I'm changing to feature request.
*** Bug 298208 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > and I can promise that it will also be present in 4.6.4, 4.7.0 most > likely also in 4.8.0, 4.9.0, 5.0.0 and so on. Maybe with Wayland we will > be able to fix it. Myth: In the open-source software bugs are fixed faster than the closed course software, because everyone can potentially fix it just looking at the code.
(In reply to comment #3) > A possible solution to the problem would be to listen to the screen locking > attempt and disabling the effect. But I'm not sure whether there is such a > signal before the screen locker tries to lock the screen and even if the > timing is difficult. > > So this also needs adjustments in kscreenlocker to try several times to lock > the screen. As that needs new functionality I'm changing to feature request. Most of the effects if not all can be *cancelled* using ESC. I am sure you explored this opportunity, but why not cancelling all effects in the screen lock code?
*** Bug 313690 has been marked as a duplicate of this bug. ***
Just wanted to hook in here. By accident I moved the cursor to the top left while suspending my laptop. After resuming I saw the present windows effect, screen was not locked. As the screenlocker was rewritten with 4.10, can this issue be handled easier? Also if you are not sure if powerdevil has such signals - why not just ask or implement? ;) Furthermore I think it would be better if the screen gets locked BEFORE the laptop sleeps. After resuming I can see the windows for a moment (up to seconds sometimes). A screenlocker is not just for preventing input but also for preventing people from looking at what you are doing. Disabling key grabbing effects + locking the screen before suspending would fix all those issues (IMHO).
(In reply to comment #8) > As the screenlocker was rewritten with 4.10, can this issue be handled > easier? In principal? No. > Also if you are not sure if powerdevil has such signals - why not just ask > or implement? ;) Powerdevil is probably not the right candidate here. The screenlocker would have to issue some "BUT I WANT!!!" before trying to obtain the grab - not a global solution, though (because every popup/combo dropdown from any application would still "break" it) Now with my Bespin hat on (ie. free thinking, "there's a solution, no matter how ugly it is") one could try to have the screenlocker query all mapped toplevel windows, unmap them (except for the own one, of course) what will make the X server release any grab (unmapped windows cannot maintain an input grab), grab the pointer and then remap all windows, BUT (<- big, fat "but"): this has of course impact on the windows, notably on the one which held the grab (assume it was a popup: it grabbed the mouse in order to hide itself on outside clicks, what is no longer gonna happen now. For the effect input window you might no longer be able to exit the effect through the mouse corner, because that's eventually covered by some other toplevel window, eg. an autohiding panel etc., also clients may simply destroy windows on unmapping ...) - for similar reasons, detecting the grabbing client this way (the one after unmapping the grab attempt suddenly is successful...) and just not re-mapping it is dangerous, because you eventually leave the foreign application in an wrong state. tl;dr - one could likely enforce the grab, but that's glitchy. The fundamental issue here is the occasional requirement to grab an input device for exclusive input handling and the lack of a way to break it or an official (NETWM) protocol to negotiate priorities (by client messages) and thus wide range support for such protocol among *all* clients (since this goes *far* beyond window effects) > Furthermore I think it would be better if the screen gets locked BEFORE bug #313123
(In reply to comment #6) > Most of the effects if not all can be *cancelled* using ESC. I am sure you > explored this opportunity, but why not cancelling all effects in the screen > lock code? Short-sighted approach. Randomly pressing escape because you're not able to grab the mouse not only requires the XTest extension (well, that'd be still acceptable) or without effect (would be bearable) but is pot. really dangerous, because you don't know *what* grabs the mouse and *how* it will react on pressing escape. If you didn't read the above comment: this has nothing to do with window effects in particular - anything could hold the mousegrab. > Myth: > In the open-source software bugs are fixed faster... This is not a bug in code, but a structural defect in the X11 protocol, which is likely older than you, and it requires a protocol extension, not a code fix. Truth: fixing protocol defects is easier in a dictatorship, yes. Who votes for me as your dictator?
I'm surprised the bug is still open... The problem solves itself once we are on Wayland, therefore RESOLVED LATER.
*** Bug 325592 has been marked as a duplicate of this bug. ***
*** Bug 338962 has been marked as a duplicate of this bug. ***
Changing to fixed as this works now (Plasma 5.5) on kwin_wayland, on x11 of course not.
*** Bug 364634 has been marked as a duplicate of this bug. ***
*** Bug 406636 has been marked as a duplicate of this bug. ***
*** Bug 406709 has been marked as a duplicate of this bug. ***
Git commit 3604aaf74cac587757b20daea108f80ade9973d5 by David Edmundson. Committed on 23/06/2019 at 16:00. Pushed by davidedmundson into branch 'master'. Close screen grabbing effect when screensaver starts Summary: The screenlock fails on X11 if it can't grab the keyboard. We can't nicely solve the generic case. We can solve the common case of a kwin effect being active. It's not critical, arguably not even desirable to have these effects persist after the screen is locked through an external trigger. We can just close the effect early. Key grabs have to be relased early before the close animation completes so that the locker doesn't have a race based on animation times. It's not ideal, but no worse than the current state for not much work. Test Plan: locked screen on a timer opened various effects Reviewers: #kwin, zzag Reviewed By: #kwin, zzag Subscribers: ngraham, zzag, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D20890 M +1 -0 CMakeLists.txt M +1 -0 effects.cpp M +10 -0 effects/cube/cube.cpp M +8 -0 effects/desktopgrid/desktopgrid.cpp M +4 -0 effects/flipswitch/flipswitch.cpp M +3 -0 effects/presentwindows/presentwindows.cpp M +7 -0 libkwineffects/kwineffects.h M +7 -2 screenlockerwatcher.cpp M +4 -1 screenlockerwatcher.h https://commits.kde.org/kwin/3604aaf74cac587757b20daea108f80ade9973d5