After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 316180 - Withdrawn windows staying around
Withdrawn windows staying around
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: X11
2.6.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
: 307877 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-09-13 12:02 UTC by Tommi Komulainen
Modified: 2011-02-04 16:19 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10


Attachments
testcase (1.71 KB, text/plain)
2005-09-13 12:04 UTC, Tommi Komulainen
Details
testcase with workarounds (3.77 KB, text/plain)
2005-09-15 13:42 UTC, Tim Janik
Details

Description Tommi Komulainen 2005-09-13 12:02:08 UTC
When a window is mapped and withdrawn quickly enough, sometimes a patch remains
on the screen where the window used to be.

Reproducable with gtk+ 2.6.10 and metacity 2.10.2
Comment 1 Tommi Komulainen 2005-09-13 12:04:24 UTC
Created attachment 52163 [details]
testcase

Double-clicking on the 'click me' leaves a gray patch of the 'label' window.
Comment 2 Matthias Clasen 2005-09-13 16:53:21 UTC
Must be some race condition with the window manager. It doesn't happen when run
without a wm.
Comment 3 Matthias Clasen 2005-09-13 17:10:13 UTC
Elijah, do you have any idea ? Ray and I do remember looking at a similar bug in
the past, but we don't know where the bug was and how we resolved it (if we
resolved it).
Comment 4 Billy Biggs 2005-09-13 17:53:46 UTC
Possibly a dup of bug 307877.
Comment 5 Matthias Clasen 2005-09-13 18:00:29 UTC
Thanks for the pointer. Yes, looks like a dup.

*** This bug has been marked as a duplicate of 307877 ***
Comment 6 Tim Janik 2005-09-14 09:56:40 UTC
i can reproduce this using sawfish. since 307877 is a metacity bug, i'm
reopening this as a gtk+ bug.
Comment 7 Tommi Komulainen 2005-09-15 08:32:31 UTC
Originally the bug was seen with matchbox but these days it's working around the
issue.
Comment 8 Tim Janik 2005-09-15 13:42:02 UTC
Created attachment 52273 [details]
testcase with workarounds

basically what happens is that the xserver gets a map command immediately
followed by an unmap command for the same toplevel xwindow. if a window manager
is running, the map command is turned into a MapRequest which is sent to the
window manager, so the following unmap command attempts to unmap a not yet
mapped window and is ignored.
here's a new attachment that shows off the behaviour at the gtk+, gdk and xlib
level. it also implements two possible workarounds, one is using
gtk_widget_show_now(), the other is setting up an event handler to enforce
unmapping.
Comment 9 Tim Janik 2005-09-15 13:43:42 UTC
fixed by means of comitting:

Thu Sep 15 15:27:55 2005  Tim Janik  <timj@imendio.com>
        * gtk/gtkwindow.c: 
        gtk_window_map_event(): new function to work around lost unmap requests.
        fixes bug #316180.

Comment 10 Elijah Newren 2005-09-15 16:28:33 UTC
*** Bug 307877 has been marked as a duplicate of this bug. ***
Comment 11 Elijah Newren 2005-09-15 16:31:18 UTC
Will the fix be applied to gtk-2-8 as well?  It applies cleanly and works for
all the testcases I have available.

Thanks for fixing this Tim!
Comment 12 Matthias Clasen 2005-09-15 17:45:17 UTC
Reopening on 2.8.4 milestone so I don't forget to get this
Comment 13 Frederic Crozat 2005-09-16 12:39:09 UTC
hmm, patch didn't fix the first testcase.
Comment 14 Elijah Newren 2005-09-16 12:51:16 UTC
Frederic: Which patch did you use and what are you referring to as the first
testcase?
Comment 15 Frederic Crozat 2005-09-16 12:56:17 UTC
I tested http://bugzilla.gnome.org/attachment.cgi?id=52163&action=view with
gtk-2-8 CVS where Tim committed the gtk_window_map_event() function today.
Comment 16 Frederic Crozat 2005-09-16 13:18:44 UTC
forget my initial comment, my gtk 2.8 build was broken.

patch is indeed working.

sorry for the false alarm.