We have at least one report of that in some cases, the action F8 -> Disconnect does not work. In this case, it is possible though to deselect fullscreen, and then disconnect. The details are still a bit unclear, but nevertheless we have found a code path in vncviewer which is not quite right. If we are waiting for more VNC data, the vncviewer will not correctly evaluate the "exitMainloop" variable.
Some more details: The theoretical scenario is as follows: 1. We receive a partial RFB message. The RFB core will then block for more data, and call the block handler in vncviewer. 2. The block handler calls FLTK's main loop in order to keep the UI running. 3. Disconnect is selected, or the window is closed. This sets an internal flag to break the primary main loop. We will now fail to exit as we are currently stuck inside RFB's blocking loop, rather than the top main loop. The UI is still responsive as we keep calling FLTK, but you cannot break the RFB block. The only way out of that is if sufficient data arrives, or the socket throws an error. So we need to add a way to break the RFB block as well when we are planning to exit. Throwing an exception is one way of getting out of it.
I think we have workarounds for this in place already. Need to retest. This will also definitely be resolved once this PR gets merged: https://github.com/TigerVNC/tigervnc/pull/1029
Was able to reproduce the issue with ThinLinc client 4.2.0 on Fedora 33 and server build 2366 on Ubuntu 20.04. Scenario ======== 1. Log in, run something that will cause lots of graphical updates. I used this video of snow fall: https://www.youtube.com/watch?v=jh_KFTYJnDo 2. Jump to an unbuffered part of the video. 3. Turn off the network on the server. I used ifconfig: > sudo ifconfig <network> down 4. Go to the client and press F8 -> Disconnect. Nothing should happen. Note that this scenario only reproduces it sometimes, for me 3 out of 10 times. The other times the client closed when I clicked Disconnect. Also, step 2 might not be necessary, but I had the most luck when including it and then doing step 3 quite quickly after.
Tested with client build 2284 on Fedora 33 and server build 2366 on Ubuntu 20.04. I tested the scenario from comment 4, and 15 out of 15 tries successfully disconnected. It seems like this issue has been solved.
Should also be tested with 4.13.0 to see if it was solved by this fix [1] or if it was fixed before it. [1]: https://github.com/TigerVNC/tigervnc/pull/1029
Also tested the scenario in comment 4 with ThinLinc client 4.13.0 on Fedora 33 and server build 2366 on Ubuntu 20.04. 15 out of 15 tries successfully disconnected, indicating that this was fixed before our latest upgrade of TigerVNC (bug 7785).
This issue was fixed some time between 4.2.0 and 4.13.0.
