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.
Unicode support using UltraVNC's clipboard extension: https://github.com/CendioOssman/tigervnc/tree/clipboard
Renamed the branch. Can now be found here: http://git.cendio.se/cgit/~ossman/tigervnc.git/log/?h=exclipboard
I've done some more work on this: https://github.com/TigerVNC/tigervnc/pull/834
That work is now merged, so we're just waiting for a vendor drop.
Upstream issue for this in noVNC: https://github.com/novnc/noVNC/issues/61
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!
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".
The same rangeError exists in Chrome on Linux. However, this issue is should now be fixed with the new vendor drop of noVNC.
(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!
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.
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.
This was actually caused by bug 7111 and has been fixed on that bug.
