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 548993 - regression: gdk 2.13 leaves stray windows in certain cases
regression: gdk 2.13 leaves stray windows in certain cases
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: X11
2.13.x
Other Linux
: Normal major
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2008-08-22 11:47 UTC by Benjamin Otte (Company)
Modified: 2009-05-30 23:44 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
swfdec-window-leak.patch (444 bytes, patch)
2008-08-25 20:59 UTC, Ed Catmur
committed Details | Review

Description Benjamin Otte (Company) 2008-08-22 11:47:52 UTC
THis bug was first reported as https://bugs.freedesktop.org/show_bug.cgi?id=16817 and https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/250769

Swfdec-mozilla uses gdk_window_new() on a parent window created via gdk_window_foreign_new() and then gdk_window_add_filter(). This way it gets its own GDK window while Firefox can continue running in the background. Sice GTK 2.13 this window is not automatically destroyed anymore when the browser page is closed, but instead happily hovers above the browser causing crashes.

We have tested that this bug is related to GTK, as it happens with GTK 2.13, but not 2.12 with identical Swfdec and Firefox versions.

I'm marking this as major as it's a regression to 2.12.
Comment 1 Priit Laes (IRC: plaes) 2008-08-22 13:05:30 UTC
It seems to be caused by commit in revision 20695:

2008-06-27  Emmanuele Bassi  <ebassi@gnome.org>

	Abstract some GdkWindow API into an interface that the backends
	must implement. (based on a patch by Alex Larsson)

	* gdk/Makefile.am: Add gdkwindowimpl.[ch]

	* gdk/gdk.symbols: Move symbols around.

	* gdk/gdkinternals.h:
	* gdk/gdkwindowimpl.[ch]: Move some of the GdkWindow API we require
	from the backends to a GInterface that the backends should implement
	instead.

	* gdk/gdkwindow.c: Provide some of the GdkWindow public API as a
	wrapper call around the GdkWindowImpl interface vtable.

	* gdk/x11/gdkevents-x11.c:
	* gdk/x11/gdkgeometry-x11.c:
	* gdk/x11/gdkprivate-x11.h:
	* gdk/x11/gdkwindow-x11.c:
	* gdk/x11/gdkwindow-x11.h: Update the X11 backend to implement
	the GdkWindowImpl interface.
Comment 2 Ed Catmur 2008-08-25 20:59:51 UTC
Created attachment 117367 [details] [review]
swfdec-window-leak.patch

This seems to work (and it's the obvious behaviour change in the diff Priit pointed to above).

Need to consult with Emmanuele/Alex about what the show in gdk_window_reparent is for, though.
Comment 3 Emmanuele Bassi (:ebassi) 2008-08-25 21:08:21 UTC
I was merely porting from Alex's code - which was against 2.8. :-(

admittedly, I never tested it with firefox+swfdec. my bad.

Ed: your patch looks fine to me.
Comment 4 Matthias Clasen 2008-08-26 01:54:21 UTC
I assume we want to change other backends reparent implementations to return FALSE, too ? 
Comment 5 Frederic Crozat 2008-08-26 08:26:56 UTC
I can confirm the patch fixes the swfdec regression.
Comment 6 Daniel Gryniewicz 2008-08-27 16:14:55 UTC
I can confirm it, too.
Comment 7 Matthias Clasen 2008-08-28 00:32:56 UTC
2008-08-27  Matthias Clasen  <mclasen@redhat.com>

        * gdk/x11/gdkwindow-x11.c:
        * gdk/win32/gdkwindow-win32.c: Return FALSE from reparent
        implementations to avoid #548993. Patch by Ed Catmur.
Comment 8 Björn Lindqvist 2008-08-30 00:17:15 UTC
(In reply to comment #2)
> Need to consult with Emmanuele/Alex about what the show in gdk_window_reparent
> is for, though.

Doc says "The window being reparented will be unmapped as a side effect." So the show block can't be right because it is the total opposite. :) 

Comment 9 Cosimo Cecchi 2009-02-05 00:39:05 UTC
Is there any other reason for this bug to stay open?
Comment 10 Björn Lindqvist 2009-05-30 23:44:21 UTC
I don't think so. For the last problem Bug 546817 is probably more appropriate.