Bug 7782 - Cannot switch to application on other monitor on macOS
Summary: Cannot switch to application on other monitor on macOS
Status: NEW
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: VNC (show other bugs)
Version: trunk
Hardware: Mac macOS
: P2 Normal
Target Milestone: MediumPrio
Assignee: Bugzilla mail exporter
URL:
Keywords:
Depends on: 7785
Blocks: keyboard
  Show dependency treegraph
 
Reported: 2021-10-27 17:10 CEST by Samuel Mannehed
Modified: 2022-02-09 15:46 CET (History)
1 user (show)

See Also:
Acceptance Criteria:


Attachments

Description Samuel Mannehed cendio 2021-10-27 17:10:50 CEST
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.
Comment 1 Samuel Mannehed cendio 2021-10-27 17:11:20 CEST
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.
Comment 2 Samuel Mannehed cendio 2021-11-02 13:48:33 CET
The upstream commit that fixes this issue is:

https://github.com/TigerVNC/tigervnc/commit/72e94ca93d3ada8fb7f518fa65644d2bc172bd4b
Comment 3 Pierre Ossman cendio 2021-11-16 16:49:02 CET
Upstream issue:

https://github.com/TigerVNC/tigervnc/issues/931
Comment 4 William Sjöblom cendio 2021-12-08 15:43:11 CET
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.
Comment 5 William Sjöblom cendio 2021-12-08 16:26:12 CET
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
Comment 8 Samuel Mannehed cendio 2021-12-20 13:57:52 CET
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.
Comment 9 Samuel Mannehed cendio 2022-02-09 15:46:06 CET
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.

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