Comment 7 for bug 67919

Attached a patch to gnome-screensaver which should fix the issue.
The lock screen window has been overlaid because gnome-screensaver windows listen to x events and raise themselves whenever a MapNotify or ConfigureNotify event arrives in order to keep themselves on the very top.

Events caused by gnome-screensaver itself are ignored of course or there would be an infinite raising race on xinerama. However the unlock-window is created by a seperate program: gnome-screensaver-dialog and therefore gnome-screensaver does not recognize it as "own" window. Therefore, the other screensaver window raises itself above the other. If this actually happens depends on the order in which the events are delivered to both screensaver windows.

The patch does the following: With the current design a screensaver window can't easily see if another screensaver window is currently displaying the unlock screen. Thus, the easiest way to handle the problem is to make the unlocking-window reraise itself even it the x event came from gnome-screensaver itself. This way, even if another screensaver window raises itself as a reaction of the unlock screen appearing, the screensaver window with the unlock screen will notice and reraise itself.

@Malcolm Parsons:
I cannot reproduce the problem with gksu. Could you please give exact instructions how to reproduce?