[v3] Updating a systray menu while it's open breaks click handlers

[johnmaguire]

Description

If a background process tries to update the systray menu while the user has the menu open, any attempts to click an item in the menu will cause it to break.

As a workaround, I tried to create a new systray menu and assign it to the systray, but this does not seem to have any effect.

I also don't know of a way to check if the systray menu is open, in order to delay updating it until it's closed.

To Reproduce

Run https://github.com/johnmaguire/wails-menu-app (initial app was committed independently, so you can use the commits to quickly see how this works or apply them to your own locally-init'd Wails app)

1. Click one of the buttons that sets or updates the menu in 5 seconds.
2. Open the systray menu and wait til the logs show the menu was updated.
3. Click on the item in the systray menu
4. Receive an error that the item does not exist (should see a log message about the menu item being clicked)

Scheduling update in 5 seconds
Update scheduled
Updating menu...
5:01PM WRN MenuItem #48 not found

You can use the other update button to see that if the menu is updated while it's closed, the handlers work fine. The set menu doesn't work regardless of the menu open state.

Scheduling update in 0 seconds
Update scheduled
Updating menu...
5:02PM INF Menu 6 clicked!

Tested on macOS, have not tested this on Windows.

Expected behaviour

Need a way to update the menu while the user has it open, without breaking it.

Screenshots

No response

Attempted Fixes

No response

System Details

Wails (v3.0.0-alpha.40)  Wails Doctor

# System

┌──────────────────────────────────────────────────┐
| Name          | MacOS                            |
| Version       | 15.6                             |
| ID            | 24G84                            |
| Branding      | Sequoia                          |
| Platform      | darwin                           |
| Architecture  | arm64                            |
| Apple Silicon | true                             |
| CPU           | Apple M4 Max                     |
| CPU 1         | Apple M4 Max                     |
| CPU 2         | Apple M4 Max                     |
| GPU           | 40 cores, Metal Support: Metal 3 |
| Memory        | 128 GB                           |
└──────────────────────────────────────────────────┘

# Build Environment

┌─────────────────────────────────────────────────────────────────────────────────────────────────────┐
| Wails CLI      | v3.0.0-alpha.40                                                                    |
| Go Version     | go1.25.1                                                                           |
| -buildmode     | exe                                                                                |
| -compiler      | gc                                                                                 |
| CGO_CFLAGS     |                                                                                    |
| CGO_CPPFLAGS   |                                                                                    |
| CGO_CXXFLAGS   |                                                                                    |
| CGO_ENABLED    | 1                                                                                  |
| CGO_LDFLAGS    |                                                                                    |
| DefaultGODEBUG | containermaxprocs=0,decoratemappings=0,tlssha1=1,updatemaxprocs=0,x509sha256skid=0 |
| GOARCH         | arm64                                                                              |
| GOARM64        | v8.0                                                                               |
| GOOS           | darwin                                                                             |
└─────────────────────────────────────────────────────────────────────────────────────────────────────┘

# Dependencies

┌────────────────────────────────────────────────────────────────────────┐
| Xcode cli tools | 2410                                                 |
| npm             | 10.9.2                                               |
| *NSIS           | Not Installed. Install with `brew install makensis`. |
|                                                                        |
└─────────────────────── * - Optional Dependency ────────────────────────┘

# Checking for issues

 SUCCESS  No issues found

# Diagnosis

 SUCCESS  Your system is ready for Wails development!

Need documentation? Run: wails3 docs
 ♥   If Wails is useful to you or your company, please consider sponsoring the project: wails3 sponsor

Additional context

No response

[johnmaguire]

Just for clarity, this is distinct from #4630 in that I do not need the ability to update the menu "in real-time" (i.e. it's OK if the menu is not updated until the user closes it and reopens it.) But I do need the existing click handlers to continue to work if the menu is updated.

[johnmaguire]

I think the best solution for this might be to detect if the menu is open when menu.Update() is called. If it is open, instead of updating, set a flag to queue an update. Then, when it's detected that the menu is closed, check if there is a pending update and update if so.

This could even potentially be implemented in userland on macOS - I'm looking at https://v3alpha.wails.io/learn/events/#menu-events but I can't quite figure out which menu was opened/closed.

[leaanthony]

Thanks for reporting this. I think the solution to the other ticket may cover this due to the way it will work. I have a local branch that needs a bit more testing so as soon as I'm ok with it will open a PR, then maybe we can test both issues?

[johnmaguire]

@leaanthony Thank you! Please keep me updated - I am happy to test any potential fixes.

[jasikpark]

I think https://github.com/wailsapp/wails/commit/81c9f4da9e1df631425720de71692ce26581e437 and https://github.com/wailsapp/wails/commit/274747d71acef562dc70efa602eb0b6aa381745a link to the WIP but the polished PR is probably better to test.