[Parity Check] Investigate Menu component

[github-actions]

Component Parity Investigation

Component: Menu
Carbon React Version: 11.113.0
Commit: a57cf8a
Status: Missing in Ember implementation

Investigation Tasks

• Review React implementation: https://github.com/carbon-design-system/carbon/tree/main/packages/react/src/components/Menu
• Check Storybook examples: https://react.carbondesignsystem.com/?path=/docs/components-menu--overview
• Document component API (props, events, variants)
• Assess implementation complexity
• Determine priority (High/Medium/Low)
• Create implementation plan or decide to skip

Resources

• Carbon React Component
• Storybook Documentation
• Carbon Design System

---

Auto-generated by parity-check script on 2026-08-01T12:37:24.168Z

[patricklx]

Implemented in #738.

Findings: Menu was missing in Ember. Implemented as a context-menu-style component with nested submenu support, keyboard navigation (arrow keys, Escape, Enter/Space), and MenuItem, MenuItemDivider, MenuItemGroup, MenuItemRadioGroup, and MenuItemSelectable subcomponents. MenuItemRadioGroup and MenuItemSelectable support both controlled (@selectedItem/@selected) and uncontrolled (@defaultSelectedItem/@defaultSelected) selection state, matching Carbon React's API.

[patricklx]

Follow-up on #738: fixed a bug found while re-verifying the implementation.

• scanFeatures unconditionally reassigned the @tracked hasIcons/hasSelectableItems properties on every scan, which retriggered its own MutationObserver in a loop and rewrote the class attribute during the same render computation that had already read it (tripping Ember's backtracking-rerender assertion). Now only assigns when the computed value actually changes, and defers the initial scan to the next frame (matching positionMenu's existing pattern).
• Fixed menu-test.gts: the root Menu renders via {{in-element}} into document.body by default, but the tests were asserting with the default qunit-dom context, which only searches the rendering-test container, not document.body. All 10 Menu tests were failing as a result. Each test now points @target at a dedicated container appended to the body and scopes assertions to it, mirroring the existing workaround in portal-test.gts.

All 10 Menu integration tests now pass, and the addon build succeeds. Pushed to the existing branch/PR (#738).

[patricklx]

Follow-up on #738: the previous fix only stopped the feedback loop from re-firing; it did not remove it. Replaced the whole approach.

• Menu scanned for icons/selectable items with a MutationObserver on its own <ul>, watching attributes. Every class rewrite Ember did for the --with-icons / --with-selectable-items modifiers fed straight back into the observer callback, which set tracked state the same render had already read. That is a backtracking-rerender assertion in dev and an endless revalidation loop in production — the cause of the docs preview hanging.
• Items now register with their parent menu (the same pattern Carbon React uses via context, and this repo already uses in ProgressIndicator/Tabs). Both modifier classes are derived from the registered items, so they stay reactive to items being added/removed and no longer depend on an icon's async SVG landing in the DOM.
• Also fixed the docs examples: they now pass a local element as @target, so the menu renders inside the preview's shadow root instead of escaping to document.body, where the preview's styles do not reach it and it rendered unstyled in the page's top-left corner.

Pushed to the existing branch/PR (#738).