When the ThinLinc Client is in fullscreen on one monitor and "send system keys" is enabled, we don't properly release the keyboard when clicking on another macOS app on the other screen. After clicking on a different application on the other screen, Win+Tab still switches windows inside the ThinLinc session. It's expected that the ThinLinc Client releases the grab when clicking outside the session in order to allow Win+Tab to switch between macOS apps instead. I tested trying to switch focus to both Safari on the non-fullscreen monitor, a terminal window and a finder window. It doesn't seem to be related to what kind of application I try to switch to. The bug can be reproduced on both macOS 11.6 and macOS 12.1.
I can also reproduce this using TigerVNC's viewer from the 1.11.0 release (the one we currently use in ThinLinc). Fortunately the issue seems fixed in the soon-to-be-released TigerVNC 1.12.0 viewer. This should be fixed after we have done a new vendordrop of TigerVNC.
The upstream commit that fixes this issue is: https://github.com/TigerVNC/tigervnc/commit/72e94ca93d3ada8fb7f518fa65644d2bc172bd4b
Upstream issue: https://github.com/TigerVNC/tigervnc/issues/931
I've tested the following different vncviewer builds and still see this problem (worth noting is that this only seem to happen when the vncviewer is in full-screen mode on the primary monitor). • Downstream vncviewer • HEAD of upstream TigerVNC master branch (commit 9d63d9c2) • At the commit that allegedly fixed the issue in upstream TigerVNC (commit 72e94ca9) • The TigerVNC 1.12.0 release build Sadly, I'm able to reproduce the issue in all of these builds. Worth noting is that we upgraded FLTK not too long ago (bug 7777). This introduced a fair number of changes for macOS. On top of this, we applied a number of macOS-specific patches to this FLTK release. So next I'll try out a couple of FLTK variations to see if that's the culprit.
I've now tested upstream vncviewer built with FLTK 1.3.5 (the previous version of FLTK used for official TigerVNC builds before the bump to 1.3.7) checked out both before and after the alleged fix. Sadly, I cannot see any change in behavior when comparing these two builds to each other and when comparing these to the seemingly identical builds in my previous comment. So, all in all, this bug can not be considered fixed in the upcoming release and should remain marked as NEW. On top of that, we should reopen the upstream issue: https://github.com/TigerVNC/tigervnc/issues/931
I have investigated this a bit further, but have not found a solution yet. I used our macOS 12.1 machine together with 2 and 3 monitors to test this. This bug is irrelevant if you only have one monitor. On macOS you will have the "dock" on one of the screens, the primary screen. The gist here is that the upstream fix does seem logically valid - that we don't grab the keyboard unless we have focus. The problem is that we don't get the proper unfocus-events. When running vncviewer in fullscreen (with grab enabled) on one of the non-primary screens I can see that I correctly get a FL_UNFOCUS event. This happens directly when clicking on a different monitor, and this leads to an ungrabKeyboard. When running vncviewer in the same way, but on the primary screen, I don't get this event. In fact, I don't get anything useful at all from FLTK on the vncviewer side of things. When looking at all the events we get from the operating system I can see a large number of NSEvent type 15: https://developer.apple.com/documentation/appkit/nsevent/eventtype/applicationdefined It is very unclear if this event includes the information we need to decide if we no longer have focus or not. At that point I dove further into FLTK seeing as that's where the proper detection for stuff like this should occur. FLTK has handling for the NSWindow notifications windowDidBecomeKey() and windowDidResignKey() which are meant to signal changes to focus: https://developer.apple.com/documentation/appkit/nswindowdelegate/1419737-windowdidbecomekey?language=objc https://developer.apple.com/documentation/appkit/nswindowdelegate/1419711-windowdidresignkey?language=objc My debug prints show that these notifications do not fire at all in this scenario. This, in turn, is why FLTK doesn't send the FL_UNFOCUS event. PS: One thing worth noting regarding the TigerVNC patch attached above is that the output from cocoa.mm won't show until after disconnecting when using tlclient. There's some sort of buffering that happens here. Due to this problem I used vncviewer directly, together with a manually started Xvnc.
To reproduce this bug you need to run the ThinLinc Client in fullscreen on the primary monitor, and you need to have "Send system keys" enabled. It is unclear why things work when we don't grab. A workaround to make the focus switch away from tlclient is to right-click on any text input field on the secondary screen.
