GNOME Bugzilla – Bug 721224
please add support for GtkSocket/GtkPlug in Wayland backend
Last modified: 2018-04-15 00:21:47 UTC
Mageia/Mandriva control center (MCC) is written in gtk+ It uses a GtkSocket in order to embed config tools when one click on the tool icon. Those tools create: - either a GtkWindow (when not embedded) - or a GtkPlug (when embedded) See eg: from https://wiki.mageia.org/en/Software_management - MCC main window: https://wiki.mageia.org/mw-en/images/d/de/SoftManage1.png - MCC embedding the 4th tool ("configure media..."): https://wiki.mageia.org/mw-en/images/9/93/ConfigMedia.png - MCC embedding the 1st tool ("install/remove software"): https://wiki.mageia.org/mw-en/images/e/e0/SoftwareSearch.png This works well under X11 but won't work anymore if/when switching from X11 to Wayland So please add support for GtkSocket/GtkPlug in the Wayland backend. Thanks
This affect other tools: http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=2355#c8 Same for XFCE panel: http://lists.freedesktop.org/archives/wayland-devel/2012-February/002030.html In that thread, they suggests several solutions: 1) Idea: Relative window Let the socket side application control the position of the plug application window. This window could be relatively positioned to the socket application window, so any transformation in the socket application can also be applied on the plug window. The plug window should be drawn on top of the socket window by the compositor and moved simultaneously. 2) Idea: Expose area Let the socket side application expose a part if its window to the plug application. This way the plug application could directly render into the socket window. The events for the exposed part should be directed to the plug application. 3) Idea: Inter client windows Share the same window between multiple clients. This way the socket side application could copy the window into its own window. The events need to be forwarded by the socket applications. 4) Idea: Shared memory Share part of the window memory between multiple applications. Either a subsection of the window or a window which is draw on top of the socket side application window. The events need to be directed to the correct process in some way. 5) Idea: Compositor in client Make the socket side application a compositor which provide a file descriptor to the plug application which gets it's window that way. The socket application needs to implement parts to act as a compositor. The plug client might need to handle multiple compositors this way.
Another affected app: http://kdekorte.blogspot.fr/2013/10/preliminary-gnome-mplayer-and-wayland.html
This seems to be a problem also for the SWT toolkit.
relevant: https://github.com/alexlarsson/wakefield
Epiphany has a problem when visiting a flash site with the latest libflashplayer.so (24.0.0.186) installed. (epiphany:12107): Gtk-WARNING **: GtkSocket: only works under X11 (epiphany:12107): Gdk-WARNING **: gdkwindow-x11.c:5573 drawable is not a native X11 window Vector smash protection is enabled. Segmentation fault (core dumped)
Note that even if gtk+ made a socket/plug implementation for wayland, the flash plugin won't work yet because it links to libgtk2-x11 itself, and is thus stuck in the ancient past.
Flash works fine with Firefox under Wayland, only Epiphany has this issue. Perhaps it's related to WebKitPluginPro, rather than the plugin itself?
(In reply to Wayne Blaszczyk from comment #7) > Flash works fine with Firefox under Wayland, only Epiphany has this issue. > Perhaps it's related to WebKitPluginPro, rather than the plugin itself? Firefox uses X11 (via Xwayland) even under Wayland, meaning NPAPI can still work. AFAIK NPAPI can't ever work without X11 since it uses native X11 types as the API.
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new