GNOME Bugzilla – Bug 303644
Withdrawn window sticking around
Last modified: 2005-07-15 04:01:22 UTC
I can reproduce a case where withdrawn windows end up not being actually withdrawn. What I need to do is map and withdraw a window really quickly after each other, as well as send a _NET_ACTIVE_WINDOW event (gdk_window_focus) on map. I will attach a testcase for the problem. xprop on the not-quite-withdrawn window has the following to say: _NET_WM_ICON_GEOMETRY(CARDINAL) = 1053, 1000, 93, 24 XKLAVIER_STATE(INTEGER) = 0, 0 WM_STATE(WM_STATE): window state: Withdrawn icon window: 0x0 _NET_FRAME_EXTENTS(CARDINAL) = 5, 5, 23, 5 WM_HINTS(WM_HINTS): Client accepts input or input focus: True Initial state is Normal State. window id # of group leader: 0x4a00001 _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL _NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 77594630 WM_CLIENT_LEADER(WINDOW): window id # 0x4a00001 _NET_WM_PID(CARDINAL) = 15176 WM_LOCALE_NAME(STRING) = "en_GB.UTF-8" WM_CLIENT_MACHINE(STRING) = "muhv" WM_NORMAL_HINTS(WM_SIZE_HINTS): program specified minimum size: 34 by 17 window gravity: NorthWest WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _N ET_WM_SYNC_REQUEST WM_CLASS(STRING) = "x", "X" WM_ICON_NAME(STRING) = "Popup" _NET_WM_ICON_NAME(UTF8_STRING) = 0x50, 0x6f, 0x70, 0x75, 0x70 WM_NAME(STRING) = "Popup" _NET_WM_NAME(UTF8_STRING) = 0x50, 0x6f, 0x70, 0x75, 0x70 This might be an X bug, but I'm filing it here for starters.
Created attachment 46275 [details] Testcase
This seems to be a race condition in metacity between mapping the window in resonse to the activate_window request, and handling the unmap notify. The code is pretty odd though. Why would you focus a window, and then immediately unmap it ?
I was seeing this when experimenting with GtkMenu: making it use managed, decorationless windows instead of override_redirect windows. Opening and closing menus real quickly would then cause this behaviour.
(Just in case anyone who doesn't know reads the bug: using managed windows for menus is impossible to make work correctly, and nobody should ever do it... Java/AWT tried to do it for a while I think, but hopefully they have now stopped)
Havoc, why ?
Two reasons: 1. you can't grab the pointer (Owen says this is OK if you want Windows-like menu behavior rather than traditional GTK behavior) 2. there's no EWMH semantic type for menus so the window manager can legitimately mess things up, by e.g. applying a placement algorithm to them
Hmm. 1. This certainly is working.. *cough* maemo *cough* 2. This is fixable. The only problem remaining is this bug. :)
1. You are grabbing the pointer, or you changed the behavior? (The reason you can't grab the pointer is that you can't grab on an unmapped window, and the WM is going to map the window for you, which means you have to wait for that to happen before grabbing, which means there's a race condition where either you grab too soon - and fail to grab - or too late - and have a period without a grab.) 2. Yes, but we have to fix it in the spec and wait for WMs to implement it properly. Why do you want these windows managed, btw? Wouldn't override redirect work fine? I'm not arguing we shouldn't fix this bug, I'm all for that, but I don't see why it's actively interfering with what you want to do.
1. Isn't that what the grab transfer window in GtkMenu is for ? 2. Yes, but not impossible. This was needed to make menus respect window stacking, which comes useful when making sure that menus close when another window is opened on top.
You can't grab transfer between two different apps. If you close the menu on loss of focus as in Windows, then opening another window should close the menu since the new window is focused. If you have a grab as in traditional GTK, opening another window shouldn't be possible normally (if one opens without user action, then having the menu stay on top is probably right). I don't know the details of Maemo but for the normal desktop that's what I'd say.
We need to change bugzilla to automatically reassign bugs when their product is changed.... *sigh* *** This bug has been marked as a duplicate of 307877 ***