Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1090122 - Pasting into java apps inserts unprintable character
Summary: Pasting into java apps inserts unprintable character
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: mingw-virt-viewer
Version: 3.3.0
Hardware: x86_64
OS: Linux
Target Milestone: ---
: 3.5.0
Assignee: Christophe Fergeau
QA Contact: Desktop QE
Depends On:
Blocks: rhev3.5beta 1156165
TreeView+ depends on / blocked
Reported: 2014-04-22 16:02 UTC by Robert McSwain
Modified: 2018-12-09 17:45 UTC (History)
17 users (show)

Fixed In Version: mingw-virt-viewer-0.6.0-2.el6_5
Doc Type: Bug Fix
Doc Text:
A difference in behavior between Linux and Windows clients caused an extra nul character to be sent when pasting text in a guest machine from a Windows client. This invisible character was visible in some Java applications. With this update, the extra nul character is removed from text strings and no more extraneous character would appear.
Clone Of:
Last Closed: 2015-02-11 17:43:48 UTC
oVirt Team: ---
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 798333 None None None Never
Red Hat Product Errata RHSA-2015:0197 normal SHIPPED_LIVE Moderate: rhevm-spice-client security and bug fix update 2015-02-11 22:35:16 UTC
GNOME Bugzilla 734670 None None None 2019-02-20 13:57:29 UTC

Description Robert McSwain 2014-04-22 16:02:27 UTC
Description of problem:
When copying from a Windows system into a java UI on a linux VM via SPICE, a trailing unprintable character is inserted. It appears as a square, but is apparently a '$'. This character is not inserted when pasting into any non-java UI, terminal, console, etc.

Version-Release number of selected component (if applicable):
RHEV 3.3

How reproducible:

Steps to Reproduce:
1. Copy a string from from a Windows system and paste it within a Java application on a RHEL guest through spice
2. Observe the square at the end of the pasted string.

Actual results:
There is a square at the end of the pasted string.

Expected results:
The string pastes as it was copied, verbatim.

Comment 2 Marc-Andre Lureau 2014-04-22 17:34:00 UTC
What virt-viewer and spice-vdagent agent do you have?

You need >=
spice-vdagent-0.14.0-1.el6 (for linux guest)
vdagent-win-3.3-1 (for windows guest)

Comment 3 Christophe Fergeau 2014-04-23 16:43:11 UTC
I just tested this with win7/0.5.622.el6_5 client (running in a VM though), and rhel6 guest with spice-vdagent 0.14.0-2. Access was done through the plugin, not.vv file.
I've tested with jedit ( ) as I do not have an easy way to get a text area in the 2 applications which are shown in the screenshots. I could not reproduce the issue. Do you get this issue with jedit ?

Comment 4 Robert McSwain 2014-04-30 14:24:07 UTC
This has been done with Virtual Machine Viewer 0.5.620.el6_5 and spice-vdagent-0.14.0-3.el6_5.x86_64. (Linux guests only). The problem also occurred on 5.6-18 and the 5.3 release of VirtViewer.

I am checking on jedit currently.

Comment 5 Marc-Andre Lureau 2014-04-30 14:33:07 UTC
could you provide the "xsel | hexdump -C" of the faulty clipboard? (it could be a trailing \0? probably not a crlf conversion issue or we would get it on each line)

Comment 6 Robert McSwain 2014-05-14 16:35:53 UTC
Here's the hexdump info:

I had to use xsel -b to get the correct clipboard info. Here is the output:

[klussier@klussier-vm1 ~]$ xsel -b | hexdump -C
00000000  41 63 74 75 61 6c 6c 79  2c 20 49 20 6a 75 73 74  |Actually, I just|
00000010  20 73 61 77 20 74 68 69  73 20 66 72 6f 6d 20 65  | saw this from e|
00000020  6e 67 69 6e 65 65 72 69  6e 67 2e 20 43 6f 75 6c  |ngineering. Coul|
00000030  64 20 49 20 67 65 74 20  79 6f 75 20 74 6f 20 70  |d I get you to p|
00000040  72 6f 76 69 64 65 20 74  68 65 20 6f 75 74 20 6f  |rovide the out o|
00000050  66 20 22 78 73 65 6c 20  7c 20 68 65 78 64 75 6d  |f "xsel | hexdum|
00000060  70 20 2d 43 22 20 6f 66  20 74 68 65 20 66 61 75  |p -C" of the fau|
00000070  6c 74 79 20 63 6c 69 70  62 6f 61 72 64 3f 20 54  |lty clipboard? T|
00000080  68 65 20 74 68 6f 75 67  68 74 20 69 73 20 74 68  |he thought is th|
00000090  61 74 20 69 74 20 63 6f  75 6c 64 20 62 65 20 61  |at it could be a|
000000a0  20 74 72 61 69 6c 69 6e  67 20 5c 30 2e 20 49 74  | trailing \0. It|
000000b0  27 73 20 70 72 6f 62 61  62 6c 79 20 6e 6f 74 20  |'s probably not |
000000c0  61 20 63 72 6c 66 20 63  6f 6e 76 65 72 73 69 6f  |a crlf conversio|
000000d0  6e 20 69 73 73 75 65 20  6f 72 20 77 65 20 77 6f  |n issue or we wo|
000000e0  75 6c 64 20 67 65 74 20  69 74 20 6f 6e 20 65 61  |uld get it on ea|
000000f0  63 68 20 6c 69 6e 65 2e  20 43 6f 75 6c 64 20 79  |ch line. Could y|
00000100  6f 75 20 63 6f 6e 66 69  72 6d 20 74 68 69 73 20  |ou confirm this |
00000110  66 6f 72 20 75 73 3f                              |for us?|

Also, this is seen with Virtual Machine Viewer 0.5.620.el6_5, 5.6-18 and the 5.3 release of VirtViewer.

Comment 7 Robert McSwain 2014-05-14 16:43:44 UTC
Also, the customer has attempted to replicate this issue with jedit, and it does not seem to happen. He is thinking that it has to do with the interaction between the clipboard and applications using swing or SWT for the UI.

Comment 8 Christophe Fergeau 2014-05-14 17:34:20 UTC
Just to be 100% sure, pasting the string you hexdump'ed in a java application exhibited this behaviour?

Comment 9 Robert McSwain 2014-05-20 18:46:58 UTC

This is correct that the above string that was copied/pasted exhibited the behavior. Thus far the following applications that have reproduced this have been Accurev, SQuirreL, and JXplorer. 

SQuirrel can be downloaded from here:
JXplorer can be downloaded from here:

Accurev is a revision control system.

Comment 10 Christophe Fergeau 2014-05-21 11:56:56 UTC
I've tested this with a win7 client, virt-viewer 0.5.6-6 32 bits. VM running on a RHEL 6.5 host. Guest OS is a RHEL 6.5 as well where I installed SQuirrel.
I've then started remote-viewer, opened Notepad on win7, typed

and pasted that to guest. I did not get the unprintable character in SQuirrel.

Comment 11 Christophe Fergeau 2014-05-22 09:28:02 UTC
Setting NEEDINFO as I'd need help or more details to reproduce.

Comment 12 Robert McSwain 2014-05-30 13:30:01 UTC
Hi all, just to confirm the environment that this is being seen in, they're running virt-viewer 0.5.6-20 64 bit on win7 64-bit guest, using native client mode not browser plugin, and the RHEL6 VM is running on RHEV Hypervisor - 6.5 - 20140407.0.el6ev, rather than a RHEL server host. It's possible a difference in environment may be why certain apps aren't able to reproduce this issue?

Comment 13 Christophe Fergeau 2014-06-02 12:57:04 UTC
I've now tested on a RHEV 3.3 instance with a 6.5 guest and win7-x64 OS/client (in a VM though) and could not reproduce this issue. I'm copying from notepad.exe, maybe you are using a different source application when you get the issue?

Comment 14 Robert McSwain 2014-06-03 14:17:20 UTC
According to the customer he can reproduce this 100% of the time copying from any application in Windows and pasting it into any of the mentioned java UIs. I have done this copying from:


Is there possibly something else that could be compared between the two?

Robert McSwain, RHCE, RHCVA 
Technical Support Engineer
Global Support Services, Red Hat, Inc.

Comment 15 Christophe Fergeau 2014-06-04 17:28:30 UTC
Is the customer running anything which can interfere with the clipboard (clipboard manager, ...) on the client or on the guest? I assume they also have some extra services running in the background on the client (antivirus, ...)?

Do you know if this has been tested on win7 32 bit versions? On a minimal Windows installation (just win7 and the client, no other program installed)? (note: I'm not saying they have to perform these tests, I'm just trying to gather more data about what has been tested so far in case this can help in reproducing this issue)

Would it be possible to get remote access to one VM where this issue happens to check if I can reproduce with my current win7 client install? 

I've just tried again with wordpad instead of notepad, and still no luck reproducing :(

Comment 16 Christophe Fergeau 2014-06-04 17:30:16 UTC
Also, did they try with a RHEL/fedora client?

Comment 18 Christophe Fergeau 2014-06-11 10:25:32 UTC
There must be an external factor coming into play here (some external application running in the background, some very specific version of a component causing the issue, ...) as I really am not able to reproduce while this occurs 100% with your customer :(

Are they installing openjdk by hand? I'm asking because versioning in RHEL looks like java-1.7.0-openjdk- , not 'jdk1.7.0_51' (but this may have come out this way when you copied the info in this bug by hand ;) Have they tried latest openjdk ? (poking in the dark here)

Comment 25 Robert McSwain 2014-07-23 13:33:48 UTC
We have tracked the bonus character down to being a null string (^@ to be exact). The SPICE client shouldn't be passing the text of the null through to the VM, but apparently it is. Since Java doesn't use null strings, it prints it.

Comment 27 Christophe Fergeau 2014-08-12 14:28:06 UTC
Filed a gtk+ bug ( ), and also sent a tentative patch for spice-gtk:

Comment 36 Marian Krcmarik 2014-09-15 15:43:56 UTC
verified with using nedit (which needs a fix from #1117764 since nedit does not work at all on RHEL guest without the patch).

Comment 39 Christophe Fergeau 2014-11-06 12:33:40 UTC
Note that the patch mentioned in bug #1161081 is most likely needed in addition to the patch in this bug to avoid a regression.

Comment 42 Julie 2015-01-27 06:19:21 UTC
Hi Christophe,
     If this bug requires doc text for errata release, please provide draft text in the doc text field in the following format:


The documentation team will review, edit, and approve the text.

If this bug does not require doc text, please set the 'requires_doc_text' flag to -.

Comment 44 errata-xmlrpc 2015-02-11 17:43:48 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

Note You need to log in before you can comment on or make changes to this bug.