Bug 3895 - Problems regarding copy/paste buffer transfer as latin1 strings
Summary: Problems regarding copy/paste buffer transfer as latin1 strings
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: VNC (show other bugs)
Version: 3.1.2
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.12.0
Assignee: Niko Lehto
URL:
Keywords: nikle_tester, relnotes, upstream
Depends on: 7373
Blocks: 3187
  Show dependency treegraph
 
Reported: 2011-07-15 11:48 CEST by Henrik Andersson
Modified: 2020-02-21 16:06 CET (History)
3 users (show)

See Also:
Acceptance Criteria:


Attachments

Description Henrik Andersson cendio 2011-07-15 11:48:23 CEST
As today the copy/past buffer that goes between client/server is latin1,
which means when copying symbols outside latin1 should consistently
be presented in a common way.

When copy utf-8 from client to server, symbols out of latin1 is presented as ?
and when copying from server to client we get an escaped string like:
\u0e44\e0e33 \u0e49\u0e1f\u0e2d\u0e33 which consistently shoudl show ?,

However, the client is now utf-8 and copy/paste buffer is latin1, which is 
not optimal, we can have translations for russian users, but they cant use 
the copy/paste... so we might need to reconsider enabling utf-8 transfer
for the copy/past operation.
Comment 1 Pierre Ossman cendio 2016-02-05 11:03:37 CET
Unicode support using UltraVNC's clipboard extension:

https://github.com/CendioOssman/tigervnc/tree/clipboard
Comment 2 Pierre Ossman cendio 2016-07-11 14:04:13 CEST
Renamed the branch. Can now be found here:

http://git.cendio.se/cgit/~ossman/tigervnc.git/log/?h=exclipboard
Comment 5 Pierre Ossman cendio 2019-05-10 16:49:37 CEST
I've done some more work on this:

https://github.com/TigerVNC/tigervnc/pull/834
Comment 6 Pierre Ossman cendio 2019-09-03 09:43:51 CEST
That work is now merged, so we're just waiting for a vendor drop.
Comment 7 Pierre Ossman cendio 2019-09-03 09:45:22 CEST
Upstream issue for this in noVNC:

https://github.com/novnc/noVNC/issues/61
Comment 8 Samuel Mannehed cendio 2020-02-05 09:57:02 CET
Tested the new code in the native client on macOS 10.15, Windows 10 and Fedora 31, all tested both ways (into session and out from session):

 ✓ regular characters
 ✓ line breaks
 ✓ smilies
 ✓ synching/not synching the depending on if the client has focus or not

Works great!
Comment 11 Alex Tanskanen cendio 2020-02-19 14:36:08 CET
Tested this with the nightly build 6392. 

What I tested:
 * regular chars
 * Unicode chars
 * line breaks
 * copy/paste in and out from a session
 * large text
 * input methods

Everything I tested against:

         | Win 10 | Linux | macOS |
 --------+--------+-------+-------+
 Chrome  |   ✓    |   ✓   |   ✓   |
 --------+--------+-------+-------+
 Firefox |   ✓    |   ✓   |   ✓   |
 -----------------+-------+-------+
 Safari  |   -    |   -   |   ✓*  |
 --------+--------+-------+-------+
 IE      |   ✓    |   -   |   -   |
 --------+--------+-------+-------+
 Edge    |   ✓    |   -   |   -   |
 --------+--------+-------+-------+

* Everything works fine on Safari, however, when copying large text in the 
session it throws an RangeError saying "Maxmimum call stack size exceeded".
Comment 12 Alex Tanskanen cendio 2020-02-21 13:27:10 CET
The same rangeError exists in Chrome on Linux. However, this issue is should now be fixed with the new vendor drop of noVNC.
Comment 13 Niko Lehto cendio 2020-02-21 13:33:41 CET
(In reply to Alex Tanskanen from comment #12)
> The same rangeError exists in Chrome on Linux. However, this issue is should
> now be fixed with the new vendor drop of noVNC.
I have now tested this with Jenkins build after vendor drop (6394.r34850). I tested large clipboard data in and out from the session in Webbaccess on:

* Windows 10
  - Internet Explorer 11
  - Microsoft Edge 44

* macOS 13
  - Safari 13

* Fedora 30
  - Chrome 80
  - Firefox 72

Seems to work good!
Comment 14 Pierre Ossman cendio 2020-02-21 15:43:08 CET
Tested on Firefox using:

https://www.ltg.ed.ac.uk/~richard/unicode-sample-3-2.html

Everything seems to transfer nicely in both directions. Also tried some large transfers (90 KiB) both ways and saw no issues.

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