Bug 4971 - Ctrl key out of sync on macOS clients
Summary: Ctrl key out of sync on macOS clients
Status: NEW
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: VNC (show other bugs)
Version: 4.1.1
Hardware: Mac macOS
: P2 Normal
Target Milestone: MediumPrio
Assignee: Pierre Ossman
Depends on:
Blocks: keyboard
  Show dependency treegraph
Reported: 2014-01-29 10:28 CET by Karl Mikaelsson
Modified: 2023-08-21 16:21 CEST (History)
2 users (show)

See Also:
Acceptance Criteria:


Description Karl Mikaelsson cendio 2014-01-29 10:28:28 CET
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.
Comment 1 Karl Mikaelsson cendio 2014-01-29 10:31:35 CET
For the record: I've seen this on my Mac mini with OS X 10.9, ThinLinc Client 4.1.1.
Comment 2 Pierre Ossman cendio 2014-02-04 15:05:00 CET
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 

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.
Comment 3 Pierre Ossman cendio 2014-09-17 10:42:05 CEST
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.
Comment 4 Pierre Ossman cendio 2021-12-14 17:11:21 CET
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:


This could easily be ported to the current stable version of TigerVNC to fix this issue.
Comment 5 Pierre Ossman cendio 2022-11-24 16:55:21 CET
Something like this is reported upstream here:


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.
Comment 7 Pierre Ossman cendio 2023-08-21 16:21:25 CEST
Also reported for noVNC:


Note You need to log in before you can comment on or make changes to this bug.