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 758660 - Copy and paste doesn't work in wayland session
Copy and paste doesn't work in wayland session
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: Wayland
3.18.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks: wayland 758713
 
 
Reported: 2015-11-25 14:57 UTC by Javier Jardón (IRC: jjardon)
Modified: 2015-11-30 19:39 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
wayland: Refactor selection ownership (3.44 KB, patch)
2015-11-30 19:05 UTC, Carlos Garnacho
committed Details | Review

Description Javier Jardón (IRC: jjardon) 2015-11-25 14:57:29 UTC
Doesnt matter I coy the text from firefox (xwalyand) or gedit (native wayland), paste doesnt work at all in any evolution window
Comment 1 Milan Crha 2015-11-25 15:28:47 UTC
Thanks for a bug report. With the "evolution window", do you mean the mail composer, or some other part of the evolution, like an event description?
Comment 2 Javier Jardón (IRC: jjardon) 2015-11-25 15:51:12 UTC
(In reply to Milan Crha from comment #1)
> Thanks for a bug report. With the "evolution window", do you mean the mail
> composer, or some other part of the evolution, like an event description?

I tried in both; neither of them worked
Comment 3 Milan Crha 2015-11-25 16:22:07 UTC
Right, I also tried in both and none works. That's quite odd. I see on the console runtime warning when pasting into the message composer body about failed assertion for 'text != NULL', which comes from e_composer_paste_text() [1].

The NULL value is returned from gtk_clipboard_wait_for_text() function call.

The issue in the top entries (To/Cc/Subject), or with the Description of an event, is even more confusing, because for example the event Description is a plain GtkTextView, the paste is handled by it. I extracted some parts of the code into a separate file and tried it out of the evolution and it worked there just fine.

I'm not sure what to try now. 

Could some clipboard content checking in the evolution empty the clipboard content?

(Unrelated, copying from devhelp doesn't work, neither middle click, like in the terminal - I just noticed).

[1] https://git.gnome.org/browse/evolution/tree/composer/e-composer-private.c#n628
Comment 4 Javier Jardón (IRC: jjardon) 2015-11-25 17:57:41 UTC
Ok, I can confirm I can reproduce this 100% of the times BUT

If I copy from evolution to another evolution window, then everything start to work as expected
Comment 5 Milan Crha 2015-11-26 17:48:31 UTC
I did more debugging of this and this is what I found:

Evolution uses the gtk_clipboard_wait_is_text_available () (and its variants) and the gtk_clipboard_wait_for_text () in the composer - I focused there, as it was the simplest place to start with for me.

Under Wayland:

* right after evolution's start, the clipboard targets are:
  clipboard:0x737c3c0 n_targets:5 (   'TIMESTAMP'=NULL
   'TARGETS'='d'
   'MULTIPLE'=NULL
   'x-uid-list'=NULL
   'STRING'=NULL
  )

  and pasting text to the composer body results in the runtime warning
  I mentioned in the comment #3.

* when I copy something from the composer's Subject GtkEntry descendant or
  the like, then the content of the clipboard changes to:
  clipboard:0x737c3c0 n_targets:10 (   'TIMESTAMP'='�|7'
   'TARGETS'='d'
   'MULTIPLE'=NULL
   'SAVE_TARGETS'=''
   'UTF8_STRING'='aaa'
   'COMPOUND_TEXT'=NULL
   'TEXT'=NULL
   'STRING'=NULL
   'text/plain;charset=utf-8'='aaa'
   'text/plain'='aaa'
  )

After this I can paste the text using gtk_clipboard_wait_for_text (). Looking into the sources of the gtk+, the gtk_clipboard_wait_for_text() expects only UTF8_STRING, while the gtk_clipboard_wait_is_text_available() checks for many many many more targets.

Under X session:

Right after start, with a text in the clipboard stored from the gedit, the content of the clipboard is:

  clipboard:0x5718580 n_targets:12 (
   'TIMESTAMP'='f:'
   'TARGETS'='�'
   'MULTIPLE'='is-NULL'
   'SAVE_TARGETS'=''
   'GTK_TEXT_BUFFER_CONTENTS'='��4׶U'
   'application/x-gtk-text-buffer-rich-text'='GTKTEXTBUFFERCONTENTS-0001'
   'UTF8_STRING'='targets_received_cb'
   'COMPOUND_TEXT'='targets_received_cb'
   'TEXT'='targets_received_cb'
   'STRING'='targets_received_cb'
   'text/plain;charset=utf-8'='targets_received_cb'
   'text/plain'='targets_received_cb'
  )

  I had "targets_received_cb" text in the clipboard.

----------------------------------------------------------------------------

I think the problem is inside the gtk+, not initializing the clipboard properly after start under Wayland. I also do not understand why the Wayland clipboard contains x-uid-list after start, but the one under X session doesn't. It probably got into consideration here [2], but I'm not sure.

[2] https://git.gnome.org/browse/evolution/tree/mail/message-list.c#n3619
Comment 6 Carlos Garnacho 2015-11-30 19:05:59 UTC
Created attachment 316548 [details] [review]
wayland: Refactor selection ownership

Dissociate ownership from our maintenance of wl_data_source objects.
The only place where ownership must be updated together is
data_source.cancelled, for the other places GDK should take care of
setting up the right ownership, even if at a different order than
we'd expect here.

This fixes GTK+ apps on wayland being locally confused about the
current selection ownership. Because gtk_selection_add_targets()
results in a wl_data_source being created, and ownership being
updated right away, early callers of this will change the ownership
even if the widget it's being called on didn't explicitly request
the selection ownership yet.
Comment 7 Carlos Garnacho 2015-11-30 19:07:55 UTC
This was indeed a gtk+ bug, moving there.
Comment 8 Matthias Clasen 2015-11-30 19:28:19 UTC
Review of attachment 316548 [details] [review]:

ok
Comment 9 Carlos Garnacho 2015-11-30 19:38:52 UTC
Attachment 316548 [details] pushed as 4f9d0c0 - wayland: Refactor selection ownership