"cargo build" OK but "cargo build --release" not OK

[conradkleinespel]

Hello all,

First of all, thanks for your hard work on this library. It's awesome to see this type of library be cross-platform too !

I'm having a weird issue where I can set the clipboard contents after running cargo build (debug mode) but I can't if I run cargo build --release. I've created a sample project to demonstrate this:
https://github.com/conradkleinespel/rust-clipboard-issue

Steps to reproduce:

• download the sample project,
• run cargo build,
• run ./target/debug/rust-clipboard-issue,
• go to a text field and hit Ctrl-V (should work fine),
• run cargo build --release instead of cargo build,
• run ./target/release/rust-clipboard-issue,
• go to a text field and hit Ctrl-V (should fail).

I'm testing on Arch Linux (with X server, not wayland).

Are you experiencing this problem to, by any chance ? Any clue on what could be the problem here ?

Thanks so much for taking the time to read this. Have a nice week.

Conrad

[aweinstock314]

I wasn't able to reproduce this issue on Debian8 with XFCE (either with https://github.com/conradkleinespel/rust-clipboard-issue or embedded in Servo), it works in both debug and release mode for me.

Specifically, I've tested (with each of rust-clipboard-issue's builds running in the background):

• CTRL-V in mousepad (the XFCE built in text editor)
• middle click in xterm (with "Select to clipboard" enabled in xterm via CTRL-middleclick)
• Servo (pasting into the textbox on './mach run -r https://wikipedia.org')

I've also tried a few pasting into mousepad/servo/xterm under similar conditions with text copied in servo via CTRL-C.

Could you share more details of your setup/which programs you've tried pasting into?

[conradkleinespel]

Thanks for taking the time to test this @aweinstock314. I will test again shortly and get back on this thread with more information about my setup.

[conradkleinespel]

@aweinstock314 I just tested again, this time on Ubuntu 16.04. Seems to work fine in release mode too. Maybe this was just an issue with my specific Arch setup. Anyway, this seems to rule out rust-clipboard itself being the issue.

Thanks again for taking the time to test this.

[jmacdonald]

I've run into this problem on Arch Linux as well. Pasting content from other programs works fine in release mode, but copying (essentially, calling set_contents) doesn't work for me. 😞

[conradkleinespel]

@jmacdonald I'm having the same problem on Ubuntu 16.04 now again. So I'm re-opening in case anyone else has more information about this.

[jmacdonald]

Even in debug mode I'm noticing strange behaviour:

1. Copy some text to the clipboard.
2. Paste text. This seems fine.
3. Copy another bit of text.
4. Paste text. The first bit of text (from step 1) is pasted.
5. Paste text again. The second bit of text (from step 3) is pasted.

It's almost as if the clipboard is behaving as a stack (albeit inconsistently). For what it's worth, xclip works fine on this system (and its copied content pastes correctly through rust-clipboard).

[Morindhal]

I too suffer from this bug using KDE Neon (based on Ubuntu 16.04).

If I compile in --release what I send to the clipboard using .set_contents( ) doesn't get caught by my systems clipboard manager, however it seems like .get_contents() gets the updated result.
If I compile in cargo's debug-profile however the updated clipboard gets caught by my systems clipboard manager.

Strange, and likely to present a problem to me later on but for now I can just stick with the debug profile.

[tkerber]

I've run into this bug too, and as far as I can tell it only affects pasting in qt-based programs. I suggest using e.g. kate to test this.

[conradkleinespel]

@aweinstock314 awesome to see this fixed with the recent PRs ! Thanks 😃