github-starred/barrier

Fork 0

mirror of https://github.com/debauchee/barrier.git synced 2026-05-15 14:16:02 -06:00

[GH-ISSUE #1387] Host MacOS loses control when zoomed in (accessibility feature) and moving cursor towards edge of viewport #1075

New issue

Open

opened 2026-05-05 07:27:15 -06:00 by gitea-mirror · 2 comments

gitea-mirror commented

2026-05-05 07:27:15 -06:00

Owner

Originally created by @CiscoFish on GitHub (Nov 5, 2021).
Original GitHub issue: https://github.com/debauchee/barrier/issues/1387

What happened?

When using the native MacOS accessibility zoom (control + scroll wheel when enabled), and moving the cursor off the edge of the zoomed sector, if in the direction of another KVM host, it will jump to it even not at a true host edge. The host MacOS system then becomes stuck and unable to zoom out our interact. The only work around is to break the network connection.

Version

v2.3.3

Git commit hash (if applicable)

No response

If applicable, where did you install Barrier from?

No response

What OSes are you seeing the problem on? (Check all that apply)

macOS

What OS versions are you using?

MacOS 10.13.6
Windows 7

Relevant log output

No helpful log outputs in this situation.

Any other information

No response

Originally created by @CiscoFish on GitHub (Nov 5, 2021). Original GitHub issue: https://github.com/debauchee/barrier/issues/1387 ### What happened? When using the native MacOS accessibility zoom (control + scroll wheel when enabled), and moving the cursor off the edge of the zoomed sector, if in the direction of another KVM host, it will jump to it even not at a true host edge. The host MacOS system then becomes stuck and unable to zoom out our interact. The only work around is to break the network connection. ### Version v2.3.3 ### Git commit hash (if applicable) _No response_ ### If applicable, where did you install Barrier from? _No response_ ### What OSes are you seeing the problem on? (Check all that apply) macOS ### What OS versions are you using? MacOS 10.13.6 Windows 7 ### Relevant log output ```shell No helpful log outputs in this situation. ``` ### Any other information _No response_

gitea-mirror added the

bug

label 2026-05-05 07:27:15 -06:00

gitea-mirror commented

2026-05-05 07:27:18 -06:00

Author

Owner

@tamsky commented on GitHub (Dec 17, 2021):

I was able to replicate this with two Macs.

If the Host is in a zoomed state and the mouse touches an active screen edge and the mouse moves to a client,
then the mouse movement on the client is extra-accelerated (large jumps between mouse positions are visible) and it takes an extraordinary amount of sustained mouse movement to return the mouse pointer across the edge back to the Host.

@tamsky commented on GitHub (Dec 17, 2021): I was able to replicate this with two Macs. If the Host is in a zoomed state and the mouse touches an active screen edge and the mouse moves to a client, then the mouse movement on the client is extra-accelerated (large jumps between mouse positions are visible) and it takes an extraordinary amount of sustained mouse movement to return the mouse pointer across the edge back to the Host.

gitea-mirror commented

2026-05-05 07:27:19 -06:00

Author

Owner

@tamsky commented on GitHub (Dec 17, 2021):

I can see why breaking the connection might be seen as the only way to fix.
It was definitely difficult to move the mouse back, but not impossible.

@tamsky commented on GitHub (Dec 17, 2021): I can see why breaking the connection might be seen as the only way to fix. It was definitely difficult to move the mouse back, but not impossible.

No labels

Rows
Columns