Comment 131 for bug 940603

From what I've read in the comments, it looks like this is similar to a problem that arose years ago with the "system tray" as it was called. (The name "system tray" came from the "systray.exe" process on MS Windows which provided some icons for what was officially known as the notification area.)

The old system tray in GNOME, following KDE's model, would occasionally fail to display icons in the tray; instead they were framed by the window manager—sawfish or sawmill at the time. It didn't always happen. It was unpredictable.

The root of the problem was a race condition. KDE's protocol required a commitment (unspecified, as I recall) from the window manager to not try to manage windows somehow marked for the system tray. Applications would map the window, the window manager would ignore it, and the system tray would reparent it. GNOME's implementation did not include the window manager commitment. Applications would map the window and both the window manager and the system tray would try to reparent it. The outcome was determined by whichever process won the race to reparent.

The subsequent freedesktop.org system tray protocol eliminated the race condition by not mapping the window destined for it before the reparenting was complete. Instead of mapping, clients were expected to send a ClientMessage to the tray. After that the XEMBED protocol took over.

It sounds like chromium is mapping when it should not be mapping. Searching through the code right now I've seen at least two places where they call XMapWindow during initialization of some objects. I must be missing something because I haven't found embedding. (But I just started minutes ago.)