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 755116 - Select/paste doesn't work from one X11 screen to another
Select/paste doesn't work from one X11 screen to another
Status: RESOLVED DUPLICATE of bug 721398
Product: gtk+
Classification: Platform
Component: Backend: X11
3.16.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2015-09-16 15:01 UTC by Grant Edwards
Modified: 2015-09-19 00:34 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Grant Edwards 2015-09-16 15:01:25 UTC
Select text in a gtk-3 application on one X11 screen (e.g. :0.0).

You can now paste it on that same screen using the middle button or
see the selected text using the command 'xclip -o'.  On another screen
in the same X11 session (e.g. :0.1) middle-click does nothing and
'xclip -o' hangs.

All X11 libraries and apps I've tried other than apps using gtk-3 do not
have this problem.  AFAIR, gtk-2 worked fine also.

Selecting text in a non-gtk-3 app on one screen and pasting into a
gtk-3 app on a different screen seems to work.  The problem is only
when the selection belongs to a gtk-3 app.  I'm guessing that each X11
screen in an X11 session has a separate set of selections/cut-buffers,
and the one is supposed to grab them on all screens in the session
when a user selects something.
Comment 1 Matthias Clasen 2015-09-19 00:25:40 UTC
This was fixed in master with

commit 55edc81c10742bf3e410168f6dc317f8aca05938
Author: Matthias Clasen <mclasen@redhat.com>
Date:   Mon Jul 27 23:18:27 2015 -0400

    x11: Make selection handling work across screens
    
    When dealing with selection events, we might see windows from
    other screens in the requestor field. The current x11 backend
    code fails to wrap these in a foreign GdkWindow, since we
    don't have the corresponding GdkScreen anymore. Work around
    this by creating such 'foreign screens' on demand. We still
    maintain the 1:1 relation between the display and the screen
    returned by gdk_display_get_default_screen().
    
    https://bugzilla.gnome.org/show_bug.cgi?id=721398

*** This bug has been marked as a duplicate of bug 721398 ***
Comment 2 Grant Edwards 2015-09-19 00:34:19 UTC
Sorry about filing a second bug on this.  I was sure I had tried to file one before, but spent hours trying to find it and couldn't.