github-starred/barrier

Fork 0

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

[GH-ISSUE #862] Mac to Mac keyboard gets unbound #687

New issue

Open

opened 2026-05-05 06:56:12 -06:00 by gitea-mirror · 9 comments

gitea-mirror commented

2026-05-05 06:56:12 -06:00

Owner

Originally created by @jbirthisel on GitHub (Aug 31, 2020).
Original GitHub issue: https://github.com/debauchee/barrier/issues/862

Describe the bug
On occasion, the mouse from server to client works, but the keyboard won't type on the client. It just stays active on whatever the server machine sees as primary app. This comes and goes and seemingly clears itself after an indeterminate amount of time.

To Reproduce

Steps to reproduce the behavior:

Use server side.
Swing mouse into client machine.
Mouse works, but keyboard stays in server.

Please do not link to image hosting sites, as these can be ephemeral. Instead, attach them to the issue.

Desktop (please complete the following information):

OS: Mac OS X
Barrier version 2.3.3- release-3394cca9

Originally created by @jbirthisel on GitHub (Aug 31, 2020). Original GitHub issue: https://github.com/debauchee/barrier/issues/862 **Describe the bug** On occasion, the mouse from server to client works, but the keyboard won't type on the client. It just stays active on whatever the server machine sees as primary app. This comes and goes and seemingly clears itself after an indeterminate amount of time. **To Reproduce** Steps to reproduce the behavior: 1. Use server side. 2. Swing mouse into client machine. 3. Mouse works, but keyboard stays in server. Please do not link to image hosting sites, as these can be ephemeral. Instead, attach them to the issue. **Desktop (please complete the following information):** - OS: Mac OS X - Barrier version 2.3.3- release-3394cca9

gitea-mirror commented

2026-05-05 06:56:17 -06:00

Author

Owner

@jbirthisel commented on GitHub (Aug 31, 2020):

It seems to be app-related. I can close things like Zoom or Office apps and it "frees" my keyboard to go to the client again.

@jbirthisel commented on GitHub (Aug 31, 2020): It seems to be app-related. I can close things like Zoom or Office apps and it "frees" my keyboard to go to the client again.

gitea-mirror commented

2026-05-05 06:56:20 -06:00

Author

Owner

@scr267 commented on GitHub (Sep 2, 2020):

I have the same issue except that it doesn't seem to be 'app' related:

Barrier worked fine for weeks switching between Mac (server) to Linux (client)
Today the same symptom as described above occurs:
-- update --
Just to confirm, a reboot did not change anything as Mac OS X kept my windows and reopened them. I closed the following applications on the Mac and the keyboard started working again on the client:

MS OneNote
Bitwarden
Terminal
TextEdit

One of these was causing the problem and re-opening them all did not successfully replicate the issue.

@scr267 commented on GitHub (Sep 2, 2020): I have the same issue except that it doesn't seem to be 'app' related: 1) Barrier worked fine for weeks switching between Mac (server) to Linux (client) 2) Today the same symptom as described above occurs: -- update -- Just to confirm, a reboot did not change anything as Mac OS X kept my windows and reopened them. I closed the following applications on the Mac and the keyboard started working again on the client: - MS OneNote - Bitwarden - Terminal - TextEdit One of these was causing the problem and re-opening them all did not successfully replicate the issue.

gitea-mirror commented

2026-05-05 06:56:23 -06:00

Author

Owner

@Tu13es commented on GitHub (Sep 24, 2020):

This seems to be related to the "secure input" mode in Catalina. I was having this issue and another app aText reported that Secure Input mode was enabled (so it too was disabled). Once I closed the other app (Zoom, in this case), Barrier started working as expected again.

@Tu13es commented on GitHub (Sep 24, 2020): This seems to be related to the "secure input" mode in Catalina. I was having this issue and another app aText reported that Secure Input mode was enabled (so it too was disabled). Once I closed the other app (Zoom, in this case), Barrier started working as expected again.

gitea-mirror commented

2026-05-05 06:56:26 -06:00

Author

Owner

@gadgetboyj commented on GitHub (Oct 10, 2020):

Thank you @jbirthisel and @za267, it turned out to be Chrome in my case. Quitting and relaunching it fixed the problem, even after reopening all of the previous tabs I had.

@gadgetboyj commented on GitHub (Oct 10, 2020): Thank you @jbirthisel and @za267, it turned out to be Chrome in my case. Quitting and relaunching it fixed the problem, even after reopening all of the previous tabs I had.

gitea-mirror commented

2026-05-05 06:56:30 -06:00

Author

Owner

@jbirthisel commented on GitHub (Oct 10, 2020):

I wonder if Barrier could detect a captured keyboard so we'd know the source of the problem?

@jbirthisel commented on GitHub (Oct 10, 2020): I wonder if Barrier could detect a captured keyboard so we'd know the source of the problem?

gitea-mirror commented

2026-05-05 06:56:32 -06:00

Author

Owner

@markplotnick commented on GitHub (Dec 7, 2020):

This happens to me infrequently enough that I forget it is Chrome's fault. Kill chrome on the mac and keystrokes from the mac start flowing freely to the Linux client again (mouse movement never stopped working).
Chrome even has a propensity to kill all networking on the mac every couple of weeks. Chrome is getting too annoying for mac use, these days.

@markplotnick commented on GitHub (Dec 7, 2020): This happens to me infrequently enough that I forget it is Chrome's fault. Kill chrome on the mac and keystrokes from the mac start flowing freely to the Linux client again (mouse movement never stopped working). Chrome even has a propensity to kill all networking on the mac every couple of weeks. Chrome is getting too annoying for mac use, these days.

gitea-mirror commented

2026-05-05 06:56:35 -06:00

Author

Owner

@chriscareycode commented on GitHub (Feb 1, 2021):

This happens to me as well, I just quit Bitwarden MacOS and the keyboard works on the clients again. Though running in the background, Bitwarden was at the login prompt screen and may be doing something special with the keyboard input, perhaps to prevent keyloggers.

@chriscareycode commented on GitHub (Feb 1, 2021): This happens to me as well, I just quit Bitwarden MacOS and the keyboard works on the clients again. Though running in the background, Bitwarden was at the login prompt screen and may be doing something special with the keyboard input, perhaps to prevent keyloggers.

gitea-mirror commented

2026-05-05 06:56:38 -06:00

Author

Owner

@markplotnick commented on GitHub (Feb 1, 2021):

Although it happens rarely, it still happens for me, it happened yesterday.
Killing chrome fixed it. It is chrome on the barrier server machine. For
whatever reason, chrome starts capturing all the keystrokes not letting
them go to the client machine even though the mouse delegation continues to
work normally.

I suppose it could be some errant plug-in in chrome causing it but it
doesn't happen often enough to warrant deep investigation since killing and
restarting chrome is enough to fix it.

My barrier server machine is a MacBook, so it is possible it is particular
to chrome on MacOs.

The way I'd investigate further, if I were you, is to start killing
processes on the barrier server machine to see if one is process is
errantly capturing keystrokes as Chrome sometimes does for me.

On Sun, Jan 31, 2021, 22:40 Chris Carey notifications@github.com wrote:

This happens to me as well, not so sure it's related to Chrome. I quit
Chrome on both machines and restarted and the issue persists

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/debauchee/barrier/issues/862#issuecomment-770558415,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AF6FCCAUETRZHUY2YMYPOW3S4YWDTANCNFSM4QQTQ3PQ
.

@markplotnick commented on GitHub (Feb 1, 2021): Although it happens rarely, it still happens for me, it happened yesterday. Killing chrome fixed it. It is chrome on the barrier server machine. For whatever reason, chrome starts capturing all the keystrokes not letting them go to the client machine even though the mouse delegation continues to work normally. I suppose it could be some errant plug-in in chrome causing it but it doesn't happen often enough to warrant deep investigation since killing and restarting chrome is enough to fix it. My barrier server machine is a MacBook, so it is possible it is particular to chrome on MacOs. The way I'd investigate further, if I were you, is to start killing processes on the barrier server machine to see if one is process is errantly capturing keystrokes as Chrome sometimes does for me. On Sun, Jan 31, 2021, 22:40 Chris Carey <notifications@github.com> wrote: > This happens to me as well, not so sure it's related to Chrome. I quit > Chrome on both machines and restarted and the issue persists > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <https://github.com/debauchee/barrier/issues/862#issuecomment-770558415>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AF6FCCAUETRZHUY2YMYPOW3S4YWDTANCNFSM4QQTQ3PQ> > . >

gitea-mirror commented

2026-05-05 06:56:41 -06:00

Author

Owner

@DarthArk commented on GitHub (Mar 26, 2021):

I have the same issue except that it doesn't seem to be 'app' related:

Barrier worked fine for weeks switching between Mac (server) to Linux (client)

Today the same symptom as described above occurs:
-- update --
Just to confirm, a reboot did not change anything as Mac OS X kept my windows and reopened them. I closed the following applications on the Mac and the keyboard started working again on the client:

MS OneNote

Bitwarden

Terminal

TextEdit

One of these was causing the problem and re-opening them all did not successfully replicate the issue.

Closed Bitwarden after seeing this and immediately fixed my issue.

@DarthArk commented on GitHub (Mar 26, 2021): > I have the same issue except that it doesn't seem to be 'app' related: > > 1. Barrier worked fine for weeks switching between Mac (server) to Linux (client) > 2. Today the same symptom as described above occurs: > -- update -- > Just to confirm, a reboot did not change anything as Mac OS X kept my windows and reopened them. I closed the following applications on the Mac and the keyboard started working again on the client: > > * MS OneNote > * Bitwarden > * Terminal > * TextEdit > > One of these was causing the problem and re-opening them all did not successfully replicate the issue. Closed Bitwarden after seeing this and immediately fixed my issue.

No labels

Rows
Columns