Repository navigation
fix(v3/windows): SetLabel/SetChecked/SetHidden/SetEnabled are no-ops - #5944
Conversation
AppendMenu with MF_POPUP uses uIDNewItem as the child HMENU, leaving submenu parent rows without the command ID that runtime mutations look up via MF_BYCOMMAND. Assign the ID by position after append. Fixes wailsapp#5943
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughWindows menu builders now restore command IDs for submenu parent items. Detached submenu handles are tracked across hiding, rebuilding, rollback, replacement, and destruction. Windows tests cover these behaviors and preserve Win32 menu-count failure values. ChangesWindows menu state
Estimated code review effort: 3 (Moderate) | ~25 minutes Possibly related PRs
Suggested labels: Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@v3/pkg/application/menu_windows.go`:
- Around line 153-158: The submenu-item restoration paths in menu_windows.go
lines 153-158 and popupmenu_windows.go lines 194-199 must check the boolean
result from assignCommandID. If assignment fails, propagate a build error from
each respective builder instead of continuing with an incorrectly mapped popup
item; preserve the existing successful build behavior.
- Around line 153-158: The submenu item restoration must use its command
identifier consistently. In v3/pkg/application/menu_windows.go lines 153-158 and
v3/pkg/application/popupmenu_windows.go lines 194-199, update SetMenuIcons to
receive menuItemImpl.id rather than the child HMENU/itemID, and propagate any
assignCommandID failure before installing bitmaps.
- Line 129: Update processMenu so that when a hidden menu item skips AppendMenu,
it destroys the newly created submenu referenced by menuItemImpl.submenu instead
of leaving it unattached; retain the existing cleanup behavior for submenus that
are appended to the visible oldHMENU.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 52411fdf-8086-40ac-951a-e98e299dcdc1
📒 Files selected for processing (3)
v3/pkg/application/menu_windows.gov3/pkg/application/menuitem_windows.gov3/pkg/application/popupmenu_windows.go
Address review feedback on the submenu command ID fix: - Check the assignCommandID result in both Windows menu builders and fail the build with an error, matching how AppendMenu and SetMenuIcons failures are already handled, instead of silently continuing with a row that cannot be addressed by MF_BYCOMMAND. - Pass menuItemImpl.id to SetMenuIcons rather than itemID. For submenu items itemID holds the child HMENU, and SetMenuIcons resolves the row via SetMenuItemBitmaps with MF_BYCOMMAND, so bitmaps on submenu rows were installed against an ID that does not exist. Non-submenu items are unaffected: there itemID and menuItemImpl.id are the same value.
There was a problem hiding this comment.
Pull request overview
This PR fixes a Windows-specific issue where runtime mutations (SetLabel, SetChecked, SetEnabled/Disabled, SetHidden) on submenu parent rows were silently ignored because those rows lacked a valid Win32 command ID and, in one codepath, didn’t retain the submenu HMENU needed for reinsertion.
Changes:
- Assign a command ID to
MF_POPUPsubmenu parent rows immediately afterAppendMenuso laterMF_BYCOMMANDupdates can locate them. - Persist the submenu
HMENUon the Windows menu item implementation so hide/show reinsertion can reattach the correct dropdown. - Fix submenu icon updates by targeting rows via the command ID (not the submenu
HMENU).
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| v3/pkg/application/popupmenu_windows.go | Assign command IDs for submenu parent rows and ensure icon updates target the command ID. |
| v3/pkg/application/menuitem_windows.go | Introduce assignCommandID helper to retroactively set Win32 command IDs by position. |
| v3/pkg/application/menu_windows.go | Persist submenu HMENU, assign command IDs for submenu parent rows, and fix icon targeting. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
…abel/SetChecked/SetHidden/SetEnabled are no-ops
…ailsapp#5944) * fix(v3/windows): assign command IDs to submenu parent menu items AppendMenu with MF_POPUP uses uIDNewItem as the child HMENU, leaving submenu parent rows without the command ID that runtime mutations look up via MF_BYCOMMAND. Assign the ID by position after append. Fixes wailsapp#5943 * fix(v3/windows): surface command ID failures and fix submenu bitmaps Address review feedback on the submenu command ID fix: - Check the assignCommandID result in both Windows menu builders and fail the build with an error, matching how AppendMenu and SetMenuIcons failures are already handled, instead of silently continuing with a row that cannot be addressed by MF_BYCOMMAND. - Pass menuItemImpl.id to SetMenuIcons rather than itemID. For submenu items itemID holds the child HMENU, and SetMenuIcons resolves the row via SetMenuItemBitmaps with MF_BYCOMMAND, so bitmaps on submenu rows were installed against an ID that does not exist. Non-submenu items are unaffected: there itemID and menuItemImpl.id are the same value. * Potential fix for pull request finding Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> * fix(v3/windows): guard against GetMenuItemCount failure in buildMenu * fix(windows): test submenu mutations and release hidden menus --------- Co-authored-by: taliesin-ai <bot@taliesin.ai> Co-authored-by: Lea Anthony <lea.anthony@gmail.com> Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
…s): SetLabel/SetChecked/SetHidden/SetEnabled are no-ops
Description
On Windows Systray menu, runtime mutations on a submenu parent row (
File ▶,Demo ▶, etc.) are silent no-ops:SetLabel,SetChecked,SetEnabled/SetDisabled, andSetHiddenupdate Go state but the native menubar/popup UI never changes. Items inside a submenu work fine; only the parent row that opens the dropdown is affected. macOS and Linux are unaffected.Severity: medium (P2). Not a crash or data loss, but a cross-platform API contract break that is hard to diagnose because Win32 failures are not surfaced to Go. Apps that dynamically update menubar submenu labels or state work on other platforms and appear broken on Windows.
Root cause:
AppendMenuwithMF_POPUPusesuIDNewItemas the child submenuHMENU, not as a command ID. Wails assigns everyMenuIteman ID and later addresses rows withMF_BYCOMMAND(SetMenuItemInfo,RemoveMenu, etc.). Submenu parents are appended without that ID, so those lookups miss and the mutation is dropped.Fix (9 lines of logic): immediately after
AppendMenufor submenu items, callSetMenuItemInfoby position to assign the Wails command ID (assignCommandID). Also store the childHMENUonmenuItemImpl.submenuinmenu_windows.go(already done inpopupmenu_windows.go) so hide/show reinsert can reattach the dropdown viagetMenuInfo().Both Windows menu builders are patched:
windowsMenu.processMenuandWin32Menu.buildMenu.Fixes #5943
Type of change
How Has This Been Tested?
Verified manually on Windows 11 with this branch:
UseApplicationMenu: true.menu.FindByLabel("Demo")(or equivalent role submenu).SetLabel,SetEnabled(false), andSetHidden(true)on that parent item.Repro code and expected behaviour are documented in #5943.
Test Configuration
Windows 11,
windows/amd64, Wails v3 source build from this branch.Checklist:
website/src/pages/changelog.mdxwith details of this PR (v3 changelog entries are added automatically)Summary by CodeRabbit
Bug Fixes