Description

v3/pkg/application/menu_linux.go (default GTK4 build) and menu_linux_gtk3.go (legacy GTK3 build) both contain a linuxMenu.processed bool field that is set to true on first call to processMenu() and used as a one-way guard:

impl := menu.impl.(*linuxMenu)
if impl.processed {
    // Menu already processed, skip re-processing to avoid duplicates
    return
}
impl.processed = true

As a result, subsequent calls to Menu.Update() (which calls m.update() → m.processMenu(m.menu)) become silent no-ops after the first call. Adding/removing menu items, rebuilding after Clear(), or any other runtime mutation will not be reflected in the native menu.

Reproduction

menu := app.NewMenu()
menu.Add("Item A")
window.SetMenu(menu)

// Later, at runtime:
menu.Add("Item B")
menu.Update()  // expected: native menu now shows Item A + Item B. actual: still just Item A.

Scope

• Affects both the default GTK4 build (this file, menu_linux.go) and the legacy GTK3 path (menu_linux_gtk3.go).
• Pre-existing — originated in feat(linux): GTK4 + WebKitGTK 6.0 support (opt-in via -tags gtk4) #4958, surfaced by Copilot review on feat(linux): flip GTK4 + WebKitGTK 6.0 to the default build (#5459) #5463 when the GTK4 code became the default path.

Suggested fix

Instead of a one-way processed guard, either:

1. Clear/destroy the native menu and rebuild from scratch on every Update() call (simpler, slight flicker).
2. Diff the current menu.items against the native menu's state and apply minimal mutations (more code, no flicker).

Option 1 is probably right unless someone reports flicker; menu updates are rare enough that the simple path is preferable.

References

• Copilot review on feat(linux): flip GTK4 + WebKitGTK 6.0 to the default build (#5459) #5463: feat(linux): flip GTK4 + WebKitGTK 6.0 to the default build (#5459) #5463 (comment)
• Original GTK4 implementation: feat(linux): GTK4 + WebKitGTK 6.0 support (opt-in via -tags gtk4) #4958