RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 872252 - EOL stripped when copying to client
Summary: EOL stripped when copying to client
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: spice-vdagent-win
Version: ---
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: David Blechter
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On: 752350 1000125
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-11-01 16:12 UTC by Tomas Jamrisko
Modified: 2019-10-10 14:19 UTC (History)
11 users (show)

Fixed In Version: vdagent-win-3.3-1
Doc Type: Bug Fix
Doc Text:
Due to issues with converting to UTF-8, EOL was stripped out when pasting text to a Windows 7 guest, and the text was pasted without new lines. This has been fixed so EOL is no longer stripped out when copying from client to guest.
Clone Of:
Environment:
Last Closed: 2014-01-21 14:42:50 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
vdagent: advertise CRLF line-ending (962 bytes, patch)
2013-06-09 13:20 UTC, Arnon Gilboa 		no flags Details | Diff
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2014:0063 0 normal SHIPPED_LIVE spice-vdagent-win bug fix and enhancement update 2014-01-21 19:41:18 UTC

Description Tomas Jamrisko 2012-11-01 16:12:55 UTC 
Description of problem:
EOL gets stripped when pasting text to a windows 7 guest

Version-Release number of selected component (if applicable):
vdagent from rhev-guest-tools-iso-3.1-8 

How reproducible:
100%

Steps to Reproduce:
1. Connect to a windows guest from whatever client (even windows)
2. Type any text with a few new lines to gedit/notepad in your client
3. Copy the text to your guest
  
Actual results:
Text gets copied without new lines 

Expected results:
Text should be copied with them
Comment 1 Tomas Jamrisko 2012-11-01 16:54:50 UTC 
Some more info --

Happens only when copying to the guest, copying from the guest works fine. 
Happens with RHEL 6.4 and Windows 7 as clients (clients are virt-viewer-0.5.2-16.el6.x86_64 and mingw-virt-viewer-0.5.3-14 )
Comment 2 Tomas Jamrisko 2012-11-01 17:44:00 UTC 
Funny thing, copying the string in guest a few times and then copying the larger clipboard back to client resulted in line ends being displayed where they should have been...
Comment 3 Christophe Fergeau 2012-11-12 14:12:05 UTC 
This is probably an issue with Windows/Linux using a different way to mark end of lines. Have you tried copying to Wordpad?
This bug is likely to be the equivalent of bug #799482 for the Windows agent.
Comment 4 Arnon Gilboa 2012-11-13 07:31:26 UTC 
(In reply to comment #3)
> This is probably an issue with Windows/Linux using a different way to mark
> end of lines. Have you tried copying to Wordpad?

Exactly. This is MS compatibility issue which is not in our hands. Win7 notepad handles eol different than notepad on xp & gedit on linux. Wordpad handles it consistently.

> This bug is likely to be the equivalent of bug #799482 for the Windows agent.
Comment 5 Tomas Jamrisko 2012-11-13 10:05:02 UTC 
(In reply to comment #4)
 
> Exactly. This is MS compatibility issue which is not in our hands. Win7
> notepad handles eol different than notepad on xp & gedit on linux. Wordpad
> handles it consistently.

The problem is, that new lines are broken even when copying from Notepad on a Windows 7 client, to Notepad on a Windows 7 guest, both 64 bit -- how can there be a compatibility issue? 

>Wordpad handles it consistently.

Yup, it does. But it's most likely, because it handles LF as a new line 

Anyway! Tried pasting contents of the clipboard to a hex editor, and it's as suspected CR LF (0x0D 0x0A) got translated to simply LF (0x0A).
Comment 6 Arnon Gilboa 2012-11-14 10:00:58 UTC 
(In reply to comment #5)
> (In reply to comment #4)
>  
> > Exactly. This is MS compatibility issue which is not in our hands. Win7
> > notepad handles eol different than notepad on xp & gedit on linux. Wordpad
> > handles it consistently.
> 
> The problem is, that new lines are broken even when copying from Notepad on
> a Windows 7 client, to Notepad on a Windows 7 guest, both 64 bit -- how can
> there be a compatibility issue? 
> 
> >Wordpad handles it consistently.
> 
> Yup, it does. But it's most likely, because it handles LF as a new line 
> 
> Anyway! Tried pasting contents of the clipboard to a hex editor, and it's as
> suspected CR LF (0x0D 0x0A) got translated to simply LF (0x0A).

Seems you are right, and it also seems to be a known result of the convertion to UTF8
http://forum.world.st/Unicode-clipboard-in-Windows-VM-td105785.html

I am still not sure we would like to keep that CR. What if Linux is in the other side? do you want to send the data with EOL format based on the target OS?
Comment 7 Tomas Jamrisko 2012-11-14 18:20:03 UTC 
(In reply to comment #6)
> 
> I am still not sure we would like to keep that CR. What if Linux is in the
> other side? do you want to send the data with EOL format based on the target
> OS?

I believe that would be the best and most consistent solution. Something along the way from guest's to client's clipboard already does the substitution of LF for CR LF. (bz #752350)

The alternative would be to simply paste a binary copy. (but there would obviously be second bug -- LF -> CR LF; but someone might require 752350 in the future)

The current behaviour of EOL is quite simply the most unintentionally inconsistent one, as it doesn't even guarantee EOL persistence between different platforms.
Comment 9 David Blechter 2012-11-20 19:46:41 UTC 
Has to be addressed the same way as https://bugzilla.redhat.com/show_bug.cgi?id=752350
Comment 11 David Blechter 2013-05-19 14:16:29 UTC 
it was a reason to keep it for now in rhevm-future - see depend on bug 752350.
please, don't change this flag without justification. We are planning to fix the problem upstream, and in rhel 6.5 first.
Comment 12 Arnon Gilboa 2013-06-09 13:20:51 UTC 
Created attachment 758795 [details]
vdagent: advertise CRLF line-ending
Comment 14 Marc-Andre Lureau 2013-08-22 18:48:59 UTC 
this isn't going to work with windows client in 3.3, since the spice-gtk bug hasn't been opened, and the patch isn't in the last mingw-virt-viewer build (mingw-spice-gtk 0.20-1).
Comment 18 errata-xmlrpc 2014-01-21 14:42:50 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.

http://rhn.redhat.com/errata/RHEA-2014-0063.html
Comment 21 Robert McSwain 2014-02-13 21:00:43 UTC 
Tomas,

Could you let me know if this is Red Hat's version of virt-viewer that you're talking about the customer trying? The most recent version from access.redhat.com is virt-viewer-0.5.6-8, so I'm unsure if you mean for the customer to try an upstream version or if this is a package which has not yet been released? The customer in question has tried the -8 release along with the packages in this bug to no avail. Thanks!
Comment 22 Christophe Fergeau 2014-02-14 08:43:54 UTC 
Robert, please answer https://bugzilla.redhat.com/show_bug.cgi?id=752350#c31 rather than having Tomas in this bug and Marc-André in the other one having to make guesses with respect to the exact test setup which was used.
Note You need to log in before you can comment on or make changes to this bug.