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: 100% 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.
What virt-viewer and spice-vdagent agent do you have? You need >= mingw-virt-viewer-0.5.6-4.el6_4 spice-vdagent-0.14.0-1.el6 (for linux guest) vdagent-win-3.3-1 (for windows guest)
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 ( http://www.jedit.org/ ) 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 ?
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.
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)
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?| 00000117 Also, this is seen with Virtual Machine Viewer 0.5.620.el6_5, 5.6-18 and the 5.3 release of VirtViewer.
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.
Just to be 100% sure, pasting the string you hexdump'ed in a java application exhibited this behaviour?
Christophe, 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: http://squirrel-sql.sourceforge.net/ JXplorer can be downloaded from here: http://jxplorer.org/ Accurev is a revision control system.
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 aaa bbb ccc and pasted that to guest. I did not get the unprintable character in SQuirrel.
Setting NEEDINFO as I'd need help or more details to reproduce.
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?
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?
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: Notepad Wordpad Word Excel Chrome Firefox Outlook Is there possibly something else that could be compared between the two? Regards, Robert McSwain, RHCE, RHCVA Technical Support Engineer Global Support Services, Red Hat, Inc.
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 :(
Also, did they try with a RHEL/fedora client?
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-1.7.0.55-2.4.7.1.el6_5.x86_64 , 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)
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.
Filed a gtk+ bug ( https://bugzilla.gnome.org/show_bug.cgi?id=734670 ), and also sent a tentative patch for spice-gtk: http://lists.freedesktop.org/archives/spice-devel/2014-August/017211.html
verified with using nedit (which needs a fix from #1117764 since nedit does not work at all on RHEL guest without the patch).
Note that the patch mentioned in bug #1161081 is most likely needed in addition to the patch in this bug to avoid a regression.
Hi Christophe, If this bug requires doc text for errata release, please provide draft text in the doc text field in the following format: Cause: Consequence: Fix: Result: 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 -.
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. https://rhn.redhat.com/errata/RHSA-2015-0197.html