Bug 3895 - Problems regarding copy/paste buffer transfer as latin1 strings
Summary: Problems regarding copy/paste buffer transfer as latin1 strings
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
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-06-16 15:38 CEST (History)
3 users (show)

See Also:
Acceptance Criteria:


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:

Comment 2 Pierre Ossman cendio 2016-07-11 14:04:13 CEST
Renamed the branch. Can now be found here:

Comment 5 Pierre Ossman cendio 2019-05-10 16:49:37 CEST
I've done some more work on this:

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:

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:


Everything seems to transfer nicely in both directions. Also tried some large transfers (90 KiB) both ways and saw no issues.
Comment 16 Samuel Mannehed cendio 2020-06-16 13:24:10 CEST
One of the vendordrops done here or on bug 6222 seems to have broken focus-on-click in Web Access in Safari on iOS. Steps to reproduce the issue:

 1. Connect a physical keyboard to an iOS device
 2. Connect to a ThinLinc session and open a terminal
 3. Type using the keyboard in the session, observe that it works
 4. Open the toolbar and press the ThinLinc logo
 5. Type using the keyboard, observe that typing no longer works
 6. Click in the session, observe that typing still doesn't work

I have verified that ThinLinc 4.11.0 does not have the problem with step 6 above.
Comment 17 Pierre Ossman cendio 2020-06-16 15:38:24 CEST
This was actually caused by bug 7111 and has been fixed on that bug.

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