Steps to reproduce: 1. Connect using the ThinLinc client on Windows 2. In the session, open the app QGIS and open the default project "Bee Farming" 3. On the Windows side (client-side), copy a image 4. Notice that the QGIS app freezes, (the rest of the ThinLinc session is functional)
Note: The "default project" mentioned above is not part of the QGIS. It was downloaded separately from here https://docs.qfield.org/get-started/sample-projects/
The following log messages can be seen when reproducing according to Comment 0: vncviewer: > Tue Oct 01 11:30:04 2024 > Viewport: Local clipboard changed whilst not focused, will notify server > later > > Tue Oct 01 11:30:06 2024 > Viewport: Focus regained after local clipboard change, notifying server Xvnc: > Tue Oct 1 11:30:04 2024 > Selection: Remote clipboard lost, removing local ownership > > Tue Oct 1 11:30:06 2024 > Selection: Remote clipboard announced, grabbing local ownership > Selection: Grabbed PRIMARY selection > Selection: Grabbed CLIPBOARD selection > Selection: Selection request for PRIMARY (type TARGETS) > Selection: Selection request for PRIMARY (type UTF8_STRING) > Selection: Requesting clipboard data from client > > Tue Oct 1 11:30:11 2024 > Selection: Selection request for PRIMARY (type UTF8_STRING) > Selection: Requesting clipboard data from client > > Tue Oct 1 11:30:16 2024 > Selection: Selection request for PRIMARY (type UTF8_STRING) > Selection: Requesting clipboard data from client > > Tue Oct 1 11:30:21 2024 > Selection: Selection request for CLIPBOARD (type TARGETS) After some digging, I found that FLTK has support for reading either plaintext or images from the clipboard [1]. The process is like this: 1. We use Fl::add_clipboard_notify() to get notified of clipboard changes on the client OS. 2. The handler for this event in vncviewer, Viewport::handleClipboardChange(), will announce to the VNC server — that clipboard data is available. 3. When the server gets this notification, it will, in turn, announce to applications in the session, that clipboard is available. 4. The application asks for clipboard in this case, so the VNC server will send back a request for a clipboard sync to the viewer, via vncRequestClipboard() in vncSelection.c. 5. The viewer receives the clipboardRequest and calls handleClipboardRequest() from CMsgReader::readExtendedClipboard(). 6. A few layers in, Viewport::handleClipboardRequest() calls Fl::paste() which emits the FL_PASTE event. 7. In the handling of this event, in Viewport::handle(), there is some filtering that likely only let plain text clipboard data get sent. The problem for the QGIS application seems to occur when it has been notified by the VNC server that clipboard is available, and then doesn't get anything after asking for it. [1]: https://www.fltk.org/doc-1.3/group__fl__clipboard.html#gaa01ff0cf95384f8255fa80edcbe1432d
Simply preventing the viewer from sending the "announceClipboard" message to the server seems to help in this case. I fixed it in upstream TigerVNC: https://github.com/TigerVNC/tigervnc/pull/1840
Tested client 4.18.0 against server 4.18.0 running on RHEL 9. I was able to reproduce the crash in QGIS with the same procedure as in comment #0, only on Windows. It was enough to just press PrintScreen to make the program freeze. After upgrading to client 3815, the issue went away.
I did manage to trigger this issue with a Linux client using xclip: > xclip -sel clip -t STRING image.png By setting invalid data on a text target (TEXT/STRING etc.), QGIS inside the session would hang, just as described in comment #0, comment #6.
(In reply to Adam Halim from comment #7) > I did manage to trigger this issue with a Linux client using xclip: > > xclip -sel clip -t STRING image.png Note that doing this procedure locally, or inside the session, does not cause QGIS to hang.
Created attachment 1265 [details] Put Latin-1 string into PRIMARY clipboard ICCCM [1] specifies that the STRING target should only contain Latin-1 text. This means X11 applications need to convert between character encodings by themselves (UTF-8 -> Latin-1 for example). I wrote a simple X11 application that puts the characters "åäö", Latin-1 encoded (0xe5, 0xe6, 0xf6), into the PRIMARY clipboard. Here are the result of pasting the text in some applications: * chromium -> ??? * firefox -> Can't paste * GNOME terminal (GTK, ISO-8859-15) -> Can't paste * tilix (GTK, UTF-8) -> Can't paste * xterm -> "åäö" * tlclient 4.18.0 (FLTK 1.3.8) -> ??? * vncviewer (QT6) -> "åäö" * qdirstat (QT5) -> ??? * qgis (QT5) -> ??? Out of these, it looks like only xterm and QT6 properly handle the Latin-1 string and converts it to UTF-8, so it seems like this is a widespread bug. [1] https://x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM/icccm.html
There was a fix upstream [1] which has been synced with ctc. Tested server build 3930 on RHEL 9 on Fedora 40 and can confirm that running the test program in comment #9 causes QGIS in the session to hang with 4.18.0. With client build 3820, this is no longer the case. Running the test program does not cause QGIS to hang. [1] https://github.com/TigerVNC/tigervnc/pull/1916
> MUST: > * Client-side clipboard should not cause > issues inside a ThinLinc session. Indeed, we should more robustly handle cases where the clipboard contains "invalid" data. > SHOULD: > * All valid clipboard strings should > be synchronized between the client > and server. There are some cases where this is not true. See bug 8534. Closing.
