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 721224 - please add support for GtkSocket/GtkPlug in Wayland backend
please add support for GtkSocket/GtkPlug in Wayland backend
Product: gtk+
Classification: Platform
Component: Backend: Wayland
Other Linux
: Normal enhancement
: ---
Assigned To: gtk-bugs
Depends on:
Reported: 2013-12-30 01:41 UTC by Thierry Vignaud
Modified: 2018-04-15 00:21 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Thierry Vignaud 2013-12-30 01:41:31 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
- MCC main window:
- MCC embedding the 4th tool ("configure media..."):
- MCC embedding the 1st tool ("install/remove software"):

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.

Comment 1 Thierry Vignaud 2013-12-30 01:51:34 UTC
This affect other tools:

Same for XFCE panel:

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.
Comment 2 Thierry Vignaud 2013-12-30 01:53:20 UTC
Another affected app:
Comment 3 panda84 2014-09-29 15:41:50 UTC
This seems to be a problem also for the SWT toolkit.
Comment 4 Matthias Clasen 2015-12-03 15:30:03 UTC
Comment 5 Wayne Blaszczyk 2016-12-26 08:08:14 UTC
Epiphany has a problem when visiting a flash site with the latest ( 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)
Comment 6 Carlos Garnacho 2016-12-26 11:51:02 UTC
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.
Comment 7 Wayne Blaszczyk 2016-12-26 22:58:57 UTC
Flash works fine with Firefox under Wayland, only Epiphany has this issue. Perhaps it's related to WebKitPluginPro, rather than the plugin itself?
Comment 8 Jonas Ådahl 2016-12-27 01:42:07 UTC
(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.
Comment 9 Matthias Clasen 2018-02-10 05:03:54 UTC
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.
Comment 10 Matthias Clasen 2018-04-15 00:21:47 UTC
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: