GNOME Bugzilla – Bug 701613
XEmbed doesn't work with frame-synced GTK/Mutter
Last modified: 2013-07-22 22:39:24 UTC
Frame-synced GTK/Mutter seems to have broken support for XEmbed in 3.8. To reproduce: - make sure to have GTK >= 3.7.10 and mutter >= 3.7.90 (the versions where frame sync was introduced) - from the GTK checkout run tests/testsocket - click on "Add Active Child" - in some cases, the child won't appear; if that happens you'll manage to make appear by clicking the button again a couple of times - when it appears, the child appears not reactive to events; try e.g. hovering over a button and it will not prelight - click events will go through, e.g. clicking on the combobox triggers the dropdown menu, but selecting an item won't update the appearance of the combobox itself - hiding and showing the child again (i.e. clicking on the "Blink" button) will refresg the child to the current view All suspicions point to something going wrong with the frame sync between GTK and Mutter. I tested the following configurations: * GTK >= 3.7.10 + Mutter >= 3.7.90 -> buggy * GTK >= 3.7.10 + Mutter 3.7.5 -> ok * GTK 3.7.8 + Mutter >= 3.7.90 -> ok * GTK 3.7.8 + Mutter 3.7.5 -> ok
Tim (darkxst) identified this bug as being the root cause between a regression on Ubuntu. https://bugs.launchpad.net/bugs/1181632 With GNOME 3.6, it was possible to run gnome-shell on lightdm (gdm is installed but not running). With GNOME 3.8, the password entry field on the unlock screen doesn't show any characters being typed in. Entering the password works but it's very confusing to users. The not-so-minimal test case: 1. Install Ubuntu GNOME "Saucy" from http://cdimage.ubuntu.com/ubuntu-gnome/daily-live/current/ 2. sudo apt-get install lightdm 3. sudo service stop gdm (This will kill your running X session) 4. sudo service start lightdm 5. Log in to GNOME Shell 6. Lock the screen. The password entry field should show ● for each character you type.
Reassigning to GTK+ - this has nothing to do with Mutter. I think the right fix is probably to make the GtkPlug code call some (new) gdk_x11_window_disable_frame_sync() On the toplevel when the window is embedded. Alternatively, we could try to make the code in gdk/x11 recognize when the window is reparented into something other than a window manager decoration, but that is tricky - you'd have to do something like walk up the hierarchy and see if the embedder or any of the parents have WM_STATE set. It's easier to do it in the GtkPlug code which already knows what is going on.
Created attachment 247832 [details] [review] Disable frame sync for GtkPlug Plug windows weren't redrawing properly because the embedded window was expecting to get messages for each frame from the compositor, but the compositor doesn't know about embedded windows. Simply disable frame sync for GtkPlug's GdkWindow - extending XEMBED to handle frame sync isn't interesting at this point. A new API gdk_x11_window_set_frame_sync_enabled() is added to allow this to be done.
Review of attachment 247832 [details] [review]: Thanks for the patch, Owen! ::: gdk/x11/gdkwindow-x11.c @@ +5338,3 @@ + } + + */ Should be GDK_WINDOW_IMPL_X11 (window->impl)->frame_sync_enabled = frame_sync_enabled; ::: gdk/x11/gdkwindow-x11.h @@ +174,3 @@ guint32 timestamp); +void gdk_x11_window_set_frame_sync_enabled (GdkWindow *window, + gboolean frame_sync_enabled); Does this need to be both here and in gdkx11window.h?
Owen, anychance of getting this patch committed? it does fix our issue with gnome-screensaver.
Patch pushed to master and gtk-3-8 Attachment 247832 [details] pushed as e061305 - Disable frame sync for GtkPlug