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?

(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

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

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

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

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.

This was indeed a gtk+ bug, moving there.

Review of attachment 316548 [details] [review]:

ok

Attachment 316548 [details] pushed as 4f9d0c0 - wayland: Refactor selection ownership