Bug 752350 - RFE: copy & paste: translate end of line sequences to target OS native ones
Summary: RFE: copy & paste: translate end of line sequences to target OS native ones
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: spice-gtk
Version: 6.2
Hardware: All
OS: All
low
low
Target Milestone: rc
: 6.5
Assignee: Christophe Fergeau
QA Contact: Desktop QE
URL:
Whiteboard:
Keywords: FutureFeature
Depends On:
Blocks: 1083163 799482 872252 1000125
TreeView+ depends on / blocked
 
Reported: 2011-11-09 09:26 UTC by David Jaša
Modified: 2018-12-09 16:45 UTC (History)
16 users (show)

(edit)
Feature: translate end of line sequences to target OS native ones during copy and paste

Reason: linux and Windows use different end of line sequences

Result (if any): line endings are silently translated when copying and pasting between Linux and Windows if the SPICE guest agent has support for this feature
Clone Of:
: 799482 1000125 (view as bug list)
(edit)
Last Closed: 2013-11-21 08:23:48 UTC


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:1577 normal SHIPPED_LIVE spice-gtk bug fix and enhancement update 2013-11-21 00:40:45 UTC

Description David Jaša 2011-11-09 09:26:49 UTC
Description of problem:
When copying plain text from gnome-terminal in RHEL guest to notepad in Windows client, notepad displays all the content on single line. This is most probably caused by newline sequences sent as-is. 

IMO, we should detect if client and guest OS's newline sequences match and if they don't they should be translated: e.g. when copying from RHEL client to Windows guest, \n sequences should be converted to \r\n.

Version-Release number of selected component (if applicable):
0.8 series

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 2 Dragan Milivojevic 2012-02-09 13:45:37 UTC
Same thing with Fedora 16 client and Windows XP guest.

BTW this feature (auto translation) is present in vmware server, vmware workstation etc and its transparent (no option to disable/enable it).

Comment 5 RHEL Product and Program Management 2012-07-10 06:04:54 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 6 RHEL Product and Program Management 2012-07-11 01:59:30 UTC
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.

Comment 7 Marian Krcmarik 2012-08-01 13:39:59 UTC
Moving to spice-gtk since the bug is reproducible over there and spice-client is being dropped.

Comment 8 David Blechter 2012-10-05 12:24:27 UTC
out of time for 6.4.

Comment 11 Hans de Goede 2013-06-24 07:38:35 UTC
I'll be writing a patch for this, so assigning this to me, until said patch is upstream.

Comment 12 Hans de Goede 2013-06-24 19:28:19 UTC
Patch posted upstream, moving to post:
http://lists.freedesktop.org/archives/spice-devel/2013-June/013736.html

Comment 15 Hans de Goede 2013-07-01 07:53:38 UTC
Patch is upstream now, re-assigning to spice-gtk RHEL maintainer, please add to the next build.

Note to QA, testing this requires using a Linux agent with bug 799482 fixed, or a Windows agent with bug 872252 fixed.

Comment 16 Christophe Fergeau 2013-07-29 15:50:06 UTC
This is now built, Hans can you check the doc text is correct?

Comment 18 Hans de Goede 2013-07-29 16:36:06 UTC
(In reply to Christophe Fergeau from comment #16)
> This is now built, Hans can you check the doc text is correct?

Doc text looks good to me, thank you for taking care of this.

Comment 20 Marc-Andre Lureau 2013-08-23 14:26:55 UTC
(In reply to David Jaša from comment #0)
> Description of problem:
> When copying plain text from gnome-terminal in RHEL guest to notepad in
> Windows client, notepad displays all the content on single line. 

Not true with gtk+ client. Gtk+ already does to and from conversion, so Windows client to Linux guest c&p just works already.

However the problematic combination is Windows->Windows or Linux->Windows, since gtk+ convert to utf8 LF. I am quite sure Hans patch only solved Linux->Windows. Hans have you tried with windows client?

Since that bug is about RHEL client, we can leave it as is, or we can remove it from QA until there is a better solution upstream.

I am working on patches to fix this.

Comment 21 Hans de Goede 2013-08-23 15:14:21 UTC
(In reply to Marc-Andre Lureau from comment #20)
> (In reply to David Jaša from comment #0)
> > Description of problem:
> > When copying plain text from gnome-terminal in RHEL guest to notepad in
> > Windows client, notepad displays all the content on single line. 
> 
> Not true with gtk+ client. Gtk+ already does to and from conversion, so
> Windows client to Linux guest c&p just works already.
> 
> However the problematic combination is Windows->Windows or Linux->Windows,
> since gtk+ convert to utf8 LF.

??? There is no such thing as UTF-8 LF, UTF-8 is capable of encoding both CR and LF. Do you mean under win 32 gtk does automatic line-ending conversion (which is an orthogonal problem from character encoding) ?

> I am quite sure Hans patch only solved
> Linux->Windows. Hans have you tried with windows client?

No, but I did try conversion in both directions by putting CRLF ending text in the clipboard under Linux
and having the Linux client think it was a windows client from a line-ending pov. To be precise for this test I hardcoded CLIENT_LINEEND_LF to 0 and CLIENT_LINEEND_CRLF to 1. With this hack + injecting CRLF terminated text into the X-windows clipboard on the client I tested copy paste from a "Windows" client to a Linux guest and the CRLF line-endings where correctly converted into Unix style LF line-endings.

IOW unless gtk-win32 does some sort of line-ending conversion itself under the hood (and I cannot really think of good reasons for it to do that), when you build the windows client using new enough spice-gtk code this should all just work.

Comment 22 Marc-Andre Lureau 2013-08-23 16:12:29 UTC
(In reply to Hans de Goede from comment #21)
> (In reply to Marc-Andre Lureau from comment #20)
> > (In reply to David Jaša from comment #0)
> > > Description of problem:
> > > When copying plain text from gnome-terminal in RHEL guest to notepad in
> > > Windows client, notepad displays all the content on single line. 
> > 
> > Not true with gtk+ client. Gtk+ already does to and from conversion, so
> > Windows client to Linux guest c&p just works already.
> > 
> > However the problematic combination is Windows->Windows or Linux->Windows,
> > since gtk+ convert to utf8 LF.
> 
> ??? There is no such thing as UTF-8 LF, UTF-8 is capable of encoding both CR
> and LF. Do you mean under win 32 gtk does automatic line-ending conversion
> (which is an orthogonal problem from character encoding) ?

I know, I mean gtk+ uses UTF-8 LF internally.

See also this bug I opened for more details:
https://bugzilla.gnome.org/show_bug.cgi?id=706657

> > I am quite sure Hans patch only solved
> > Linux->Windows. Hans have you tried with windows client?
> 
> No, but I did try conversion in both directions by putting CRLF ending text
> in the clipboard under Linux

That's not good enough. It just doesn't work with Windows client. I am sending patches to the ML this evening.

Comment 23 Marc-Andre Lureau 2013-08-23 21:01:48 UTC
new patch series:
http://lists.freedesktop.org/archives/spice-devel/2013-August/014219.html

Comment 24 Hans de Goede 2013-08-24 09:55:20 UTC
(In reply to Marc-Andre Lureau from comment #22)

<snip> 

> I know, I mean gtk+ uses UTF-8 LF internally.
> 
> See also this bug I opened for more details:
> https://bugzilla.gnome.org/show_bug.cgi?id=706657

Ugh. having gtk strip all the CR-s is bad. This means we need to re-insert the CR-s when doing windows <-> windows copy - paste. And this also means that if in windows we've text with just LF-s in the clipboard and we copy it to/from windows we and up inserting CR-s, thus modifying the text.

Anyways, I realize there is nothing we can do here as long as gtk is not fixed, thanks for filing the gtk bug.

I agree that adding back the CR-s when doing windows <-> windows copy paste is the best we can do for now, so I'll go and review your patch-set for this.

<snip>

Regards,

Hans

Comment 29 errata-xmlrpc 2013-11-21 08:23: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.

http://rhn.redhat.com/errata/RHBA-2013-1577.html

Comment 33 Marc-Andre Lureau 2014-02-17 21:40:31 UTC
Robert, 

Are you running >= vdagent-win-3.3-1 in the Windows guest?

Can you provide SPICE_DEBUG=1 remote-viewer log?

thanks


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