After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 561567 - compiz expo can break the screensaver lock
compiz expo can break the screensaver lock
Status: RESOLVED NOTGNOME
Product: gnome-screensaver
Classification: Deprecated
Component: general
2.24.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-screensaver maintainers
gnome-screensaver maintainers
Depends on:
Blocks:
 
 
Reported: 2008-11-19 18:45 UTC by Michael Vogt
Modified: 2008-12-19 18:12 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Michael Vogt 2008-11-19 18:45:16 UTC
When gnome-screensaver is used with the compiz expo plugin, the screensaver can be bypassed when expo is put onto a mouse modified. It seems like the reason for this is that the keyboard is grabbed, but the mouse pointer is released from the grab when the unlock dialog comes up (gs-manager.c:1106).
Comment 1 Michael Vogt 2008-11-20 17:12:39 UTC
I looked into this a bit and it seems like its difficult (impossible?) to have a gdk_grab_pointer() for the GtkPlug that shows the unlock dialog. Without a pointer grab I see not a lot of options to prevent expo from being activated. 

g-s-s could talk to compiz via dbus and disable expo while the dialog is up. This is obviously a pretty suboptimal solution.
Comment 2 William Jon McCann 2008-11-20 19:50:14 UTC
Thanks for the report.  Ray and I haven't been able to reproduce this.  Could you describe exactly what you do to make this happen?  What exacly do you mean by "bypass"?  The most we've been able to do is to have the expo plugin show 4 side by side locked screens.  Thanks.
Comment 3 Michael Vogt 2008-11-20 21:22:18 UTC
Thanks for your replay and sorry that I wasn't more clear in my initial report. 

I did the following:
1. open compizconfig-settings-manager (ccsm)
2. go to "expo" and then "Bindings" 
3. set "Expo button" to something like "<Shift>Button1"
4. lock the screen 
5. press shift-button1 -> this triggers compiz to go into expo  mode
6. drag the black background gnome-screensaver window aside (just click and move the window)
7. use shift-button1 to again to go to the desktop again 

(the "expo button" binding is disabled by default in upstream compiz).

I hope this is better, if anything is unclear I'm happy to try to describe it better (this is tested with compiz 0.7.8 and gnome-screeensaver 2.24.0).

Thanks,
 Michael
Comment 4 Michael Vogt 2008-11-21 11:01:04 UTC
After some further debugging and discussing with compiz upstream it looks like
its a compiz problem (quoting one of the main developers):
"<maniac103> mvo: expo doesn't filter override_redirect windows ... " 

Sorry for the noise.
Comment 6 eMBee 2008-12-09 09:45:10 UTC
the compiz fix only prevents moving the screensaver window, it does not prevent activating the expo plugin nor does it prevent the expo plugin from receiving mouse events. in this case it is still possible to move windows around (even if they can't be seen).

for proper locking NO event must be allowed to be received by anything except the lock window. therefore this IS a gnome/gtk issue.
Comment 7 eMBee 2008-12-09 10:07:47 UTC
xscreensaver behaves properly btw, so this shows that correct locking is possible and does not depend on how compiz/expo handles mouse events
Comment 8 Danny Baumann 2008-12-19 11:19:19 UTC
(In reply to comment #6)
> the compiz fix only prevents moving the screensaver window, it does not prevent
> activating the expo plugin nor does it prevent the expo plugin from receiving
> mouse events. in this case it is still possible to move windows around (even if
> they can't be seen).

I fail to see how this is possible. expo goes through the window stack (top-down) until it finds a window your pointer is in. If it is and you're allowed to move it (not override_redirect, move action set etc.), movement is initiated. Otherwise, movement is cancelled. Could you provide steps to reproduce what you're describing?

> for proper locking NO event must be allowed to be received by anything except
> the lock window. therefore this IS a gnome/gtk issue.

Well, yeah.

Comment 9 eMBee 2008-12-19 12:36:15 UTC
* set up a few large (easier to grab) windows on different viewports (remember where they are)
* lock the screen
* invoke expo
* try to grab a window from a different viewport (not the one you are on while invoking expo) and move. you will see the active viewport highlight as you move the window.
* release the mouse and unlock screensaver
* find a window moved...
Comment 10 Danny Baumann 2008-12-19 12:59:46 UTC
(In reply to comment #9)
> * set up a few large (easier to grab) windows on different viewports (remember
> where they are)
> * lock the screen
> * invoke expo
> * try to grab a window from a different viewport (not the one you are on while
> invoking expo) and move. you will see the active viewport highlight as you move
> the window.
> * release the mouse and unlock screensaver
> * find a window moved...

The requirement to be on a different viewport than the moved window was the missing link. Fixed (commit 991de5e00758a236b31ee60ed31a7d605a0a76d4 in expo), thanks.
Comment 11 eMBee 2008-12-19 17:15:45 UTC
thanks.
i only discovered that missing link after you asked.

it is great that expo is being fixed, but i am still wondering how it is possible that expo gets access to mouse events in the first place. this is still an issue that imho needs to be fixed in the gnome-screensaver, because besides expo there could be other applications that could receive those events...
Comment 12 Danny Baumann 2008-12-19 18:12:47 UTC
(In reply to comment #11)
> thanks.
> i only discovered that missing link after you asked.
> 
> it is great that expo is being fixed, but i am still wondering how it is
> possible that expo gets access to mouse events in the first place. this is
> still an issue that imho needs to be fixed in the gnome-screensaver, because
> besides expo there could be other applications that could receive those
> events...

Indeed. I checked today with KDE: expo is not usable with an active kscreensaver, even without having the latest fixes applied. This tells us that it _is_ possible to do it correctly.