Every now and then on the Mac OS X client, the Ctrl key behaves like it's been pressed while it's not. I haven't yet figured out what key combination triggers this, but I mostly experience this in Emacs which has lots of key combinations with Ctrl. Pressing Ctrl again makes it get back in sync.
For the record: I've seen this on my Mac mini with OS X 10.9, ThinLinc Client 4.1.1.
We got a customer report on issue 14942. The issue also describes a way to reproduce the problem: "It can be caused by holding (cmd+shift+4) (used on mac to make a screenshot)" I verified this on our 10.9 machine in the lab with ThinLinc in windowed mode, and it resulted in state 0x9 getting stuck. Pressing and releasing first shift, then cmd got me back to normal.
There are two bugs at play here. One is a server side issue where it gets confused about two Alt_L presses with a shift in between and without a release. This has been moved to bug 5258. The other bug is that we do not see the release of Cmd and Shift when 4 is grabbed as a hot key. Need to add some logic for this, probably triggering a release of all keys like we do for loss of focus.
I encountered this in another scenario: If you press Cmd+Tab but cycle back to the ThinLinc, then Cmd (Alt from the server's point of view) gets stuck down until you push it again. The problem is that such system actions steal keyboard input, but don't generate focus change events. However, there is an event that is sent once it is done stealing input. Namely a NSFlagsChanged. Unlike normal such events the key code is set to 0 (which would be the "A" button, which isn't a modifier). The commit from the other work that fixes this is here: https://github.com/TigerVNC/tigervnc/pull/1375/commits/c2b852a512605f601a1caefc5498c66259233b31 This could easily be ported to the current stable version of TigerVNC to fix this issue.
Something like this is reported upstream here: https://github.com/TigerVNC/tigervnc/issues/1539 Like here, the user reported a stuck Ctrl. But Ctrl was never pressed, so I'm suspecting the user there, and here, are just assuming a bit too much about what is happening. The observed behaviour appears to be consistent with a stuck Alt, which is way more expected as that key was actually pressed.
Fixed upstream now: https://github.com/TigerVNC/tigervnc/commit/4f6d4895c3420e5ac301a916bced4a0065a19183
Also reported for noVNC: https://github.com/novnc/noVNC/issues/1799
