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.

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.

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

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.

For reference: http://gitweb.compiz-fusion.org/?p=fusion/plugins/expo;a=commit;h=f97a9fa6f0ad578f674d1f248bd7bef90e3260e0 is the compiz commit

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.

xscreensaver behaves properly btw, so this shows that correct locking is possible and does not depend on how compiz/expo handles mouse events

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

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

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

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

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