I've found, and fixed, a race condition that was causing metacity to map a window which shouldn't have been mapped, in a fairly obscure, but possible, situtation.

In our system we have a custom monitor manager which handles automatic monitor hotplug detection and configuration, etc.  We also have an app which creates windows, one per monitor, each monitor handler utilizing its own X connection.

The bug we've seen is that if a laptop with no external monitor attached is suspended, then an external monitor is attached, and the system is resumed with the lid closed, the old monitor handler is destroyed, along with its window and X connection, a new monitor handler is created along with a new X connection and window, and sometimes our app window ends up mapped in front of our lock screen, when it shouldn't.

The exact cause is as follows:

Client 1 opens X connection for laptop monitor, creates window W, maps window W.

Xorg     creates the window and redirects the maprequest to metacity.

Metacity gets redirected maprequest from the X server and maps window W.

Client 1 destroys window W and disconnects from X server.

Client 2 opens X connection for external monitor, (and gets same XID for
         window as client 1), creates window W (without mapping it).

Metacity sees window W get destroyed and in display.c:event_callback it
         calls meta_window_free (line 1960).  meta_window_free cleans up
         its data structures, pushes an error trap and at line 1193 REMAPS(!)
         the newly destroyed window.  Apparently the developer relied on
         the fact that for a destroyed window the error trap would handle
         the BadWindow X error in this case, and rather than trying to
         avoid the error just lets it happen.  The reason for remapping
         the window seems to be because the same function (meta_window_free)
         is called when metacity is shutdown, so any windows mapped by
         clients end up mapped for the new window manager.

The problem is that in this case the BadWindow error doesn't happen.  Metacity has incorrectly mapped the NEW WINDOW from Client 2, which the client never asked to be mapped.

The fix for this seems to be to avoid doing the map if the window has been
destroyed.  I have a patch that does this, although there may be a better
way to handle it.  If I can get it to attach I'll do that, else I'll add it
as an additional comment. (don't ask me why my machine keeps deleting the attachment field when I hit Commit, I don't know...)