WAYLAND_DEBUG=1 produced Wayland protocol debug output, but you may have a hard time capturing that from gnome-terminal. In any case, I think this bug should start its life on the gnome-terminal side.

See https://wiki.gnome.org/Apps/Terminal/Debugging how to debug g-t.

However, I don't see how this could be a g-t bug. It works on X, so if it doesn't on wayland, that's most likely a problem in gdk.

Fine. I'll state that it works under Wayland as well, on my system. 

GTK+ is not handling Ctrl-Shift-V. Make of it what you want, but blindly moving all bugs to GTK+ is not getting them fixed any faster.

In this case here, Shift-Ctrl-V just does:

  clipboard = gtk_widget_get_clipboard (..., GDK_SELECTION_CLIPBOARD);
  gtk_clipboard_request_targets (clipboard, ...)

and on receiving the targets:

if (gtk_targets_include_uri (targets, n_targets)) {
    gtk_clipboard_request_uris (clipboard, ....)
  } else /* if (gtk_targets_include_text (targets, n_targets)) */ {
    vte_terminal_paste_clipboard (VTE_TERMINAL (data->screen));
  }

where vte_terminal_paste_clipboard is just gtk_clipboard_request_text().

So if the 'previously used text' is received by these request functions, I really don't see how that could be any fault of g-t/vte.

Comment 0 doesn't state from which programme the clipboard data originated; if it's g-t (via Shift-Ctrl-C) then that's just from gtk_clipboard_set_with_owner() for the GDK_SELECTION_CLIPBOARD GdkClipboard , text/plain target and the selected text as data.


Also note that vte has ZERO code that depends on the gdk backend, and g-t only has a couple such checks (WM checks (gdk_x11_screen_supports_net_wm_hint(), "window-manager-changed" signal handling) [I'll just remove these now since they're obsolete], setting of an environment variable in the child process on the X backend, and using X directly to get a fallback startup timestamp).  THAT is the basis for my assessment that a bug that occurs on wayland but not on X, is a priori unlikely to be a g-t/vte bug. So I'm not just 'blindly' moving bugs around!

@Christian The copied text came from PHPStorm IDE (so outside G-T). But I don't think the problem is related to the application where data is coming from. I also have GPaste installed, which displays clipboard history and I saw my text on the top of the list. However what I got in G-T was the second item in GPaste (so the previously copied text).

I know it's hard to guess where the problem is especially when it happens randomly. That's why I asked if there is a way to debug it. I'm thinking of enable logging of API calls made by G-T. So next time the issue happens I can present you the logs and hopefully that could help track down the problem. Is there a way to do that?

See the link in comment 2 on how to start g-t-server in a way that lets you set WAYLAND_DEBUG env var in it.

Well, did you capture the debug output with g-t-server run with WAYLAND_DEBUG set?

No, I couldn't do it. First problem is that I couldn't get gdb to save the log messages to a file by redirecting standard output. Second is that it produces a ton of messages per second, so the log file would take gigabytes after a day I guess. Some filtering would be useful here. Is there any trick to solve these problems?

By the way, the reported problem happened only once, since I created this bug ticket. I use the terminal on a daily basis. Again I copied text from a Java application into the terminal. 
If I go back to the Java app and press Crtl + C on the selected text nothing changes, wrong text will be pasted into the terminal. But when I paste the text first into another text editor like Sublime and select it, press Ctrl + C, then the pasting magically start working in the terminal. So maybe it has something to do with how Java Virtual Machine interacts with the clipboard.