Bug 872252
| Summary: | EOL stripped when copying to client | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Tomas Jamrisko <tjamrisk> | ||||
| Component: | spice-vdagent-win | Assignee: | David Blechter <dblechte> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Desktop QE <desktop-qa-list> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | --- | CC: | acathrow, cfergeau, dblechte, hesemeyt, marcandre.lureau, ngalvin, pvine, rmcswain, tdosek, tjamrisk, uril | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| 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.
|
Story Points: | --- | ||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2014-01-21 14:42:50 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | 752350, 1000125 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
|
Description
Tomas Jamrisko
2012-11-01 16:12:55 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 ) 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... 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. (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. (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). (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? (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. Has to be addressed the same way as https://bugzilla.redhat.com/show_bug.cgi?id=752350 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. Created attachment 758795 [details]
vdagent: advertise CRLF line-ending
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). 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 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! 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. |