libvncserver should not advertize ExtendedClipboard support if server app doesn't supoort it #638
Labels
Milestone
Comments
|
Yes, clipboard cleanup is the last missing bit for v0.9.15 - I just need to find some time to tackle this ;-) |
gujjwal00
added a commit
to gujjwal00/libvncserver
that referenced
this issue
Nov 19, 2024
… support for UTF-8 cut-text A UTF-8 capable client will usually prefer to send cut-text via ExtendedClipboard encoding once libvncserver declares support for it. If app doesn't assign a setXCutTextUTF8() callback, the default handler is used which is no-op. So client-to-server clipboard transfer will not work. Re: LibVNC#638
gujjwal00
added a commit
to gujjwal00/libvncserver
that referenced
this issue
Nov 19, 2024
… support for UTF-8 cut-text A UTF-8 capable client will usually prefer to send cut-text via ExtendedClipboard encoding once libvncserver declares support for it. If app doesn't assign a setXCutTextUTF8() callback, the default handler is used which is no-op. So client-to-server clipboard transfer will not work. Re: LibVNC#638
|
Opened a PR with the fix. Let me know if I can help with something else. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
libvncserver always enables ExtendedClipboard encoding if client supports it. When client sends cut text, it is reported to server app via
setXCutTextUTF8()callback, which is no-op by default. If app doesn't support UTF-8 cut text, it will not set this callback. As a result, client to server clipboard transfer will be completely broken.To my knowledge, x11vnc and Gnome Remote Desktop are affected by this.
libvncserver should check whether the callback is set before enabling ExtendedClipoard encoding. This is how libvncclient does it.
The text was updated successfully, but these errors were encountered: