This behavior is controlled by the window manager, not xscreensaver.
FAQ: http://www.jwz.org/xscreensaver/faq.html#popup-windows

To change this behavior, the window manager should be using XRestackWindows
instead of XRaiseWindow.

Metacity does map windows using XRestackWindows(). FYI, GTK_WINDOW_POPUP windows
are override-redirect windows.

This bug has been reported in Ubuntu Launchpad:

https://launchpad.net/distros/ubuntu/+source/metacity/+bug/239

Quoting comments:
---------------------------
(1)
Applications can popup above xscreensaver, while xscreesaver is locking the screen and NOTHING should be able to popup above it.

As stated on http://www.jwz.org/xscreensaver/faq.html it is a WM bug: "You might consider this a bug in your window manager (though some consider it a feature.) If you think it's a bug, then the magic incantation to repeat to the author of your window manager is as follows: ``you should be mapping windows with XRestackWindows instead of XRaiseWindow, to ensure that managed windows always appear below override-redirect windows.''"
(2)
do you have any example?
(3)
PSI jabber client, KF jabber client.

'Enable popup notifications' in PSI (options/events). These popups are placed above xscreensaver window. 'KF popups windows' too.

Take a look at
http://jabberstudio.org/cgi-bin/viewcvs.cgi/cvs/kf/src/gtktip.c?rev=1.4&view=markup

There's a code from KF that shows these 'popup windows'. They are created like:
GTK_WINDOW (tip)->type = GTK_WINDOW_POPUP;

I don't know what code does this in PSI.
(4)
koke@ababol ~/Devel/gnome/metacity $ grep -rcl XRaiseWindow * koke@ababol ~/Devel/gnome/metacity $ grep -rcl XRestack *
src/stack.c

It seems that part is ok, could you offer some help for reproducing that. I think I don't see that popups when running xscreensaver (maybe on top of a fullscreen mplayer)
(5)
Does this bug still occur?
(6)
Yeah, it still occures. Here is how I reproduced it today:

1. Psi installed on father's computer (running standard, "virgin" hoary). 2. Father's account created on jabber server.
3. Added mine jid to the roster.
4. Turned on: <menu/options/events/enable popup notifications>. 5. Screen locked, by choosing "lock screen" from AFAIR "system" menu. 6. Gone to my computer and sent a message to father's jid.

Result: the popup on father's computer (saying that new message arrived) appeared (while screen is locked).

Anyway, it's not a metacity bug? Maybe I should report it to xscreensaver authors? I use xlockmore right now (not on ubuntu) and those popups appear too, but they disappear in 0,1s. It's still a problem though...

These all is somewhat "should not happen" to me. But I don't know where the bug resists. Maybe xorg should have a mechanism that allows running one app at a time on the 'absolutely top'.
---------------------------

elijah, can i please ask you to comment here from a metacity point of view? thanks in advance.

AFAICT, Jamie's FAQ is kind of useless here.  It states ``you should be mapping windows with XRestackWindows instead of XRaiseWindow, to ensure that managed windows always appear below override-redirect windows.''  Metacity does that; however, the problem isn't with managed windows but rather with unmanaged (a.k.a. override-redirect) ones.  For metacity to possibly be at fault (or even be capable of helping workaround the problem), it would have to be managing the window being raised above the screensaver.  In other words the window would have to be managed, but GTK_WINDOW_POPUP windows are override-redirect.

Personally, I think the existence of override-redirect windows is brain-damage in X.  They shouldn't exist.  They cause all kinds of accessibility nightmares.  They have to be semi-managed anyway for compositing to possibly work (the compositing extension in X allows the WM to get the relevant information so that it can partially manage such windows).  They mean that each and every app does its own managing of such windows, and there will always be apps that are unaware of the screensaver and then create and raise windows while the screensaver is running.

Does Jamie still track bugs here? Can we close this?

Well, given that they are override-redirect windows, I don't know what xscreensaver could do to stop them from popping up, other than auto-raising itself more often.  But that would just reduce the amount of time the popup windows were visible, not eliminate it.  So, I'd be inclined to label it "feature, not bug" and ignore it...

Well that may be convenient, but it makes the screensaver useless.
The screensaver is meant to protect unauthorised people doing things on your PC.

If they can interact with a window..

First of all, you meant to say that it "makes the screen *locker* useless".  The screen *saver* still works fine.  Most people use screen savers to draw pretty pictures and don't lock their screens at all.

Second, you can't *interact* with the pop-up dialog, you can only *see* it.  xscreensaver holds the mouse and keyboard grabbed, so all input events go to xscreensaver, not to underlying applications.

Third, you can be as upset about this as you like, that doesn't change the fact that I still don't see a way to fix it.  If you think you do, send me a patch.  Or patch Metacity to not use override-redirects.  Or something.

Okay..

1. There's no such thing as a screenlocker, only a screensaver with a password.
_I_ don't know anybody that uses a screensaver without it locking their workstation.
I guess we know different people.

2. Doesn't matter. You can still see it. It might reveal something confidential.

3. Fine, you're the developer.

But it's still broken.

It's not really possible for Jamie to fix this, nor for me to do so (as metacity maintainer; the only way to currently avoid it that I can think of is to patch all applications in the universe to stop using override-redirect windows).  It'd be nice to be able to manage override-redirect windows to make them stack appropriately relative to other windows (among other things), but override-redirect means "override any management".  We'd need some kind of X extension to fix this.