menu: fix submenu dismiss propagation and ESC handling

[boboshan]

Summary

Fixes #2229 — three related fixes for submenu dismiss behavior in PopupMenu:

1. Auto-wire parent_menu in render(): Submenus added via PopupMenuItem::submenu() (the data constructor) don't get parent_menu set, unlike PopupMenu::submenu() (the builder method). This breaks the dismiss chain. Now PopupMenu::render() auto-wires parent_menu on any submenu child that doesn't have it set. This is needed because table delegates operate in Context<TableState> and cannot call PopupMenu::submenu() which requires Context<PopupMenu>.

2. Fix ESC not closing menus when a submenu is open: When a submenu is opened by hover, the parent menu retains focus. Pressing ESC would hit the parent's dismiss(), which bailed out early because active_submenu() was Some. Split dismiss into dismiss (ESC action handler that clears the active submenu first) and dismiss_menu (internal dismiss that propagates up the chain).

3. Guard handle_dismiss for submenu clicks: handle_dismiss (click-outside) returns early if a submenu is active. Without this, clicking a submenu item triggers the parent's on_mouse_down_out, tearing down the submenu before the item's on_click fires.

Changes are in popup_menu.rs only — no table code changes needed.

No dependency on #2231.

AI Disclosure

Implementation was developed with AI assistance (Claude). All code has been reviewed, tested, and follows existing popup_menu.rs patterns.

Test plan

• cargo run --example table — right-click context menu with submenus works
• cargo run (story) — Menu story context menu: ESC closes full chain
• Submenu item click fires handler and dismisses menu
• Click outside closes all menus
• Hover navigation between submenus still works

[huacnlee]

This is a monkey-patch, not a good solution.

[huacnlee]

Every frame render will hit this loop...

This is unacceptable.

[boboshan]

Thanks for the feedback — the render-time approach was wrong.

We've explored several alternatives but each has trade-offs:

Our problem: TableDelegate::context_menu() receives Context<TableState>, not Context<PopupMenu>. So the delegate can't use PopupMenu::submenu() (which auto-wires parent_menu). It must use PopupMenu::build() + PopupMenuItem::submenu(label, entity), which doesn't set parent_menu. Without it, dismiss doesn't propagate from child submenus to the root context menu.

Options we considered:

1. Wire in set_selected_index (lazy, on first hover) — works but adds parent-wiring responsibility to an unrelated method
2. Change TableDelegate::context_menu to receive Context<PopupMenu> — clean, but breaking API change
3. Wire in the table's .context_menu() closure after delegate returns (once per menu open, not per frame) — works, but accesses menu_items directly

Do you have a preferred approach, or a different idea for handling submenus built outside Context<PopupMenu>?

[boboshan]

Rebased onto current main and rewrote the wiring approach to address the per-frame objection.

The parent_menu wiring now happens once inside PopupMenu::build, after the user's builder closure populates menu_items. Every PopupMenu (context menus, dropdowns, plain popups) funnels through build, so the wiring is centralized. Nested submenus are handled because each submenu also goes through its own PopupMenu::build invocation. Zero per-frame cost.

The is_none() guard means the existing PopupMenu::submenu() builder path (which already wires parent_menu correctly) is unaffected — it just observes that the field is already set and skips. No API change to TableDelegate.

Tested locally in a downstream app with table context menus carrying nested collection submenus: ESC closes the full chain, click-outside closes everything, click on a submenu item fires the action and dismisses cleanly.