182726 - GTK 2.1 breaks gtk2xtbin

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Philip Langdale]

It would appear that some of the changes in gtk 2.1 have broken gtk2xtbin.
When plugin loading is attempted, it fails without taking mozilla down, but the
plugin fails to load. Here is the relevant console output from gtk2xtbin.

gtk_xtbin_realize()
initial allocation 0 0 749 68
xt_client_create() 
gtk_xtbin_resize 0x895fdd0 749 68
gtk_xtbin_resize 0x895fdd0 749 68
gtk_xtbin_resize 0x895fdd0 749 68

(<unknown>:13715): Gtk-WARNING **: gtksocket.c:957Can't add non-GtkPlug to GtkSocket

(<unknown>:13715): Gdk-CRITICAL **: file gdkmain-x11.c: line 648
(gdk_error_trap_pop): assertion `gdk_error_traps != NULL' failed

This is occuring with GTK 2.1.2, but I know that gtk2xtbin still worked with
a CVS build of GTK 2.1 from before the 2.1.0 release.

I guess GTK 2.1 is still in flux, but I felt it was good to put this on the 
radar

Comment 1

[Philip Langdale]

Ok, I have now confirmed that the breakage occured between 2.1.1 and 2.1.2.

There is no difference in GtkSocket code, so it is something going on at a lower
level.

Comment 2

[Robin Lu]

I haven't install gtk2.1.2 yet. I guess it's the problem of gdk_window_lookup.
For gtk2xtbin whose plugin window is from an XtWindow, we suppose the
gdk_window_lookup returns null after looking up and should never hit the code at
gtksocket.c:957. 

Comment 3

[Christopher Blizzard (:blizzard)]

*** Bug 183670 has been marked as a duplicate of this bug. ***

Comment 4

[Christopher Blizzard (:blizzard)]

*** Bug 183775 has been marked as a duplicate of this bug. ***

Comment 5

[Christopher Blizzard (:blizzard)]

*** Bug 184670 has been marked as a duplicate of this bug. ***

Comment 6

[Christopher Blizzard (:blizzard)]

Lordy.  I've just discovered that in gtk 2.1 we're actually trying to add the
socket to itself.  I'm guessing this is not by design and is a mystery to be
solved.  I'm going to have a long day tomorrow, I can tell.

Comment 7

[Christopher Blizzard (:blizzard)]

Attachment: patch

Could it be this easy? (And how did this ever work?)

Comment 8

[Christopher Blizzard (:blizzard)]

Checked in.  Yay!

Comment 9

[Christopher Blizzard (:blizzard)]

I'm going to change this to use gtk_socket_add_id() instead of
gtk_socket_steal().  I looked at the wrong set of headers and thought that
add_id() wasn't in Gtk 2.0, but it is.

Comment 10

[Christopher Blizzard (:blizzard)]

*** Bug 178501 has been marked as a duplicate of this bug. ***

Comment 11

[Robin Lu]

The ReparentNotify was why it worked in gtk2.0.x. I used gtk_socket_add_id
before but found it is redundant. The gtk_socket_add_id was not needed to be
called explicitly. When plug is created based on socket, socket should mostly
know the plug via X event. gtk_socket_add_id is mostly used when socket is
created based on the plug, which plug should know the socket via X event in this
situation. We can call gtk_socket_add_id in gtk2xtbin without any further
communication only because the plug and socket are in the same scope. IMHO, if
there's something we can do for the bug, it might be to reinforce the
reparentnotify or createnotify has been sent.
I am guessing there's some strange event triggers the socket adding to itself
before the real reparentnotify being recieved. 
Anyway, we can use the current patch to solve this.