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
I have verified that the keys no longer get stuck on macOS when upgrading to a ThinLinc client, built after our sync with upstream TigerVNC. I tested with server v4.18.0 and v4.18.0post (3923), and see that server version has no effect on this issue. But when comparing client v4.18.0 and v4.18.0post (3813), I see that the bug is no longer present in the v4.18.0post (3813), where the fixes in TigerVNC are present.
> MUST: > * Keyboard state should not become out of sync between the session and the > local macOS host when using the (installed) ThinLinc client. The keyboard now remains in sync when using the ThinLinc client on macOS.
Opened bug 8524 for tracking upstream issue mentioned in comment 7.
