GNOME Bugzilla – Bug 307877
Window left hanging around
Last modified: 2005-09-15 16:28:32 UTC
metacity 2.10.1-2 (Debian unstable) 1. Run the following example 2. Click the button 3. Notice that a frame-less window is stuck on the screen If the call to gdk_window_focus() in the code is commented out, the window does not get stuck there.
Created attachment 47847 [details] leftover.c
You got me stumped. I've been investigating this for a little while but I've run out of ideas.
*** Bug 303644 has been marked as a duplicate of this bug. ***
*** Bug 316180 has been marked as a duplicate of this bug. ***
(Note that both bug 303644 and bug 316180 have additional testcases...er, maybe "an additional testcase" since the two are virtually identical) So, I spent a bunch more time on this and I still haven't found it, but: - Whenever things work correctly (no stuck window), logs show that Metacity cleared its calc_showing_queue before receiving the _NET_ACTIVE_WINDOW message. - Whenever things break (the window is stuck), logs show that Metacity received the _NET_ACTIVE_WINDOW message before clearing the calc_showing_queue. I also tried comparing the two logs after the "(Dialog 1) withdrawn" test in each and found them to be mostly similar with the main differences being extra MapNotify, FocusIn, and FocusOut evens in the broken case. Didn't seem to tip me off right away to anything. Anyway, I'll attach the two logs...
Created attachment 52186 [details] "broken" case--log with the stuck window
Created attachment 52188 [details] working case--log with no stuck window
Oh, and in case it wasn't clear from earlier comments, this bug doesn't happen 100% of the time; it's a potshot. Also, although Billy's testcase looks kind of contrived (show the window, activate it, then immediately unmap it), the testcase(s) in the other bugs give a better idea of why this bug is likely to be triggered by users in normal programs.
Created attachment 52191 [details] [review] Working around the symptoms... I don't know why meta_window_activate() causes problems for windows that aren't yet mapped as in these testcases, but this patch does happen to fix the bug. Seems odd, though...meta_window_activate() specifically checks if the window is minimized and if so unminimizes it--but wouldn't the unminimized window have the same race that these not-yet-mapped windows have that would allow for a stuck window? Havoc: any bright ideas on what might be happening or causing problems?
note that #316180 has a gtk test case that can be used to reproduce the stuck window behaviour under sawfish.
note that bug #316180 has been fixed and contains an extended testcase plus workarounds for this bug, so you might want to just close this issue for metacity.
Gladly.... :-) *** This bug has been marked as a duplicate of 316180 ***