[GH-ISSUE #661] Java applications stop responding to keyboard input after losing and regaining window focus #521

New issue

Open

opened 2026-05-05 06:35:29 -06:00 by gitea-mirror · 6 comments

gitea-mirror commented

2026-05-05 06:35:29 -06:00

Owner

Originally created by @Feanux3 on GitHub (May 8, 2020).
Original GitHub issue: https://github.com/debauchee/barrier/issues/661

Operating Systems

Server: Windows 10 Pro 1909

Client: macOS Catalina 10.15.4

Barrier Version

2.3.2-shapshot-210c2b70

Steps to reproduce bug

Issue is most prevalent in SQLDeveloper on macOS. When the window focus is regained after losing focus (selecting any other open window/program) the program no longer recognizes keyboard input from the server. Minimizing the window and bringing it back up restores full functionality.

Other info

Issue persists across multiple Macs and operating systems
Mouse clicks will only highlight text, no longer changes the cursor to insert (if editing text)
Only appears to be an issue with Java based programs
Always reproducible
Issue happened with Synergy

Originally created by @Feanux3 on GitHub (May 8, 2020). Original GitHub issue: https://github.com/debauchee/barrier/issues/661 ### Operating Systems ### Server: Windows 10 Pro 1909 Client: macOS Catalina 10.15.4 ### Barrier Version ### 2.3.2-shapshot-210c2b70 ### Steps to reproduce bug ### Issue is most prevalent in SQLDeveloper on macOS. When the window focus is regained after losing focus (selecting any other open window/program) the program no longer recognizes keyboard input from the server. Minimizing the window and bringing it back up restores full functionality. ### Other info ### - Issue persists across multiple Macs and operating systems - Mouse clicks will only highlight text, no longer changes the cursor to insert (if editing text) - Only appears to be an issue with Java based programs - Always reproducible - Issue happened with Synergy

gitea-mirror commented

2026-05-05 06:35:33 -06:00

Author

Owner

@tehbiga commented on GitHub (May 8, 2020):

I've noticed this with IntelliJ (on macOS Mojave client).

When switching operating systems the text editor buffer doesn't properly regain focus (already an existing bug for other reasons in IntelliJ), but it happens consistently when using barrier.
I have to switch tabs back and forth to force IntelliJ to pick an editor buffer to focus on for me.

If anything, this would probably be an easier testing app since it has multiple text entries that pull focus. I bet this has something to do with how the mouse events are being emulated.

@tehbiga commented on GitHub (May 8, 2020): I've noticed this with IntelliJ _(on macOS Mojave client)_. When switching operating systems the text editor buffer doesn't properly regain focus _(already an existing bug for other reasons in IntelliJ),_ but it happens consistently when using barrier. I have to switch tabs back and forth to force IntelliJ to pick an editor buffer to focus on for me. If anything, this would probably be an easier testing app since it has multiple text entries that pull focus. I bet this has something to do with how the mouse events are being emulated.

gitea-mirror commented

2026-05-05 06:35:36 -06:00

Author

Owner

@github-actions[bot] commented on GitHub (Sep 23, 2020):

This issue has been automatically marked as stale due to inactivity. It will be closed if no further activity occurs. Thank you for your contributions.

@github-actions[bot] commented on GitHub (Sep 23, 2020): This issue has been automatically marked as stale due to inactivity. It will be closed if no further activity occurs. Thank you for your contributions.

gitea-mirror commented

2026-05-05 06:35:39 -06:00

Author

Owner

@Feanux3 commented on GitHub (Sep 23, 2020):

Still an issue - responding to keep it active.

@Feanux3 commented on GitHub (Sep 23, 2020): Still an issue - responding to keep it active.

gitea-mirror commented

2026-05-05 06:35:43 -06:00

Author

Owner

@p12tic commented on GitHub (Jan 10, 2021):