fix(desktop): keep Windows tray loop on locked thread#3717
Merged
esengine merged 1 commit intoJun 9, 2026
Conversation
This was referenced Jun 9, 2026
Closed
esengine
approved these changes
Jun 9, 2026
esengine
left a comment
Owner
There was a problem hiding this comment.
Verified on Windows: the desktop module vets clean and TestDesktopTrayLoopRunsOnLockedOSThread passes, confirming the systray loop stays pinned to one OS thread across scheduler yields. This is the correct remedy for #3516 — fyne.io/systray's Win32 message loop must pump messages on the same thread that created the hidden window, and base code ran it on a migratable goroutine. Thanks for the live repro write-up and the regression test.
SuMuxi66
pushed a commit
to SuMuxi66/DeepSeek-Reasonix
that referenced
this pull request
Jun 10, 2026
Wrap the Windows systray loop in runtime.LockOSThread() so fyne.io/systray's Win32 hidden-window message loop stays pinned to one OS thread; the scheduler migrating the goroutine left the tray unresponsive while the app was in the tray. Fixes esengine#3516.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Keep the Windows systray event loop on a locked OS thread.
Fixes #3516.
Also addresses the tray right-click/menu responsiveness symptoms reported in #3394 and the tray portion of #3548. The MCP orphan-process note in #3548 is a separate issue and is intentionally out of scope for this PR.
Why
We caught a live repro on Windows with desktop v1.4.0 where the tray icon stopped responding to right click while the app was hidden:
reasonix-desktop.exewas still alive andResponding=True.SystrayClass) still existed butIsHungAppWindow(SystrayClass) == true.wailsWindow) reportedIsHungAppWindow(...) == false.That points to the systray Win32 message loop becoming stuck independently of the main Wails window.
fyne.io/systrayrelies on Win32 hidden-window messages on Windows, so the tray loop should stay pinned to one OS thread.How
runtime.LockOSThread()beforesystray.Run(...).Testing
go test . -run 'TestDesktopTrayLoopRunsOnLockedOSThread|TestTrayMenuLabelsFollowLocale|TestBeforeCloseAllowsSystemQuitWhenBackgroundCloseEnabled' -count=1wails build