Menubar

• Menubar: a persistent bar of menu triggers with roving tabindex across the bar, ArrowLeft / ArrowRight between menus, and one menu open at a time.
• Dropdown Menu: a single trigger and its menu, with no bar and no cross-menu navigation. Choose it unless the menus genuinely belong to one bar.
• Context Menu: the same actions opened by right-click at the pointer.
• Toolbar: the same one-Tab-stop bar shape when the controls act directly (buttons, toggles) instead of opening menus.

<div forMenubar [(value)]="openMenu" ariaLabel="Application">
  <button forMenubarTrigger value="file">File</button>
  <!-- mounted when openMenu() === 'file' -->
  <div forMenuContent>
    <button forMenuItem>New file</button>
    <hr forMenuSeparator />
    <button forMenuItem>Quit</button>
  </div>

  <button forMenubarTrigger value="edit">Edit</button>
  <!-- mounted when openMenu() === 'edit' -->
  <div forMenuContent>
    <button forMenuItem>Undo</button>
    <button forMenuItem>Redo</button>
  </div>
</div>

ForMenubar ([forMenubar]) is the root: it owns value (the open trigger), orientation, dir, loop and disabled, and provides a multiplexed ForMenuContext to the active [forMenuContent]. Each ForMenubarTrigger ([forMenubarTrigger]) is a role="menuitem" button with aria-haspopup="menu" / aria-expanded / aria-controls, participating in roving tabindex and trigger-row keyboard.

The menu surface, items, separators, groups, and submenus come from the menu/ folder and are the same primitives that [forDropdownMenu] and [forContextMenu] use. The bar simply pumps a different ForMenuContext whose anchor / side / ids reflect the active trigger.

The bar provides one multiplexed ForMenuContext, so a [forMenuContent] does not have to be repeated per trigger. Three shapes are supported, and all three preserve a consumer-set static id on the surface:

For the two shared shapes the surface belongs to no single trigger, so a static id on it stays put across a menu switch and every trigger's aria-controls resolves to it. A surface with no static id gets a generated one that follows the active trigger. In every shape the accessible name (aria-labelledby / aria-label) tracks whichever trigger's menu is currently open.

Only a plain id="…" attribute is preserved. A [id]="expr" property binding evaluates after the directive is constructed, so it is invisible to the adoption and fights the surface's own [id] binding.

ForMenubar

Every output above is vetoable: each handler receives a VetoableEvent (or VetoableNativeEvent<E> when there is a native DOM event). Call preventDefault() on the emitted veto to suppress the menubar's default action; the original DOM event, when present, is on .event. The outputs are declared on [forMenubar] rather than per trigger: the bar provides a single multiplexed menu context, so one set of handlers covers whichever trigger's menu is open.

ForMenubarTrigger

Data attributes

Trigger

In-menu

Inside an open menu, the standard [forMenuContent] keyboard applies (see menu/README.md). The menubar adds:

Submenus opened from a top-level menu work as in [forDropdownMenu]: Escape collapses one level at a time, the open-key opens, and the close-key collapses upward. When the submenu's parent is the top of a menubar, the close-key on the submenu trigger collapses the parent and switches to the previous sibling menu; the away-key on a plain item inside any submenu level collapses the whole chain and switches to the next sibling menu.

[forMenubar] implements the WAI-ARIA Menubar pattern. Each trigger carries role="menuitem" with aria-haspopup="menu", aria-expanded, and aria-controls. Roving tabindex keeps one trigger in the tab sequence at a time. Disabled triggers remain focusable with aria-disabled="true" per APG. The menu surface and item roles come from the shared menu/ primitives.

forty-cdk ships no styles: put your own class on each piece and key your CSS off the data-* attributes listed under Data attributes, not off the for* selectors (Styling forty-cdk explains why).

Each trigger's menu surface is the shared [forMenuContent] (from menu/), which portals to document.body. Style it with global CSS or a class, because scoped/:host styles won't reach it. The portaled content also exposes the shared positioner custom properties (--for-floating-anchor-width / -height, --for-floating-available-width / -height, --for-floating-content-transform-origin); see Styling floating content for the full list and how to use them.

.menubar-menu-trigger[data-state='open'] {
  background: var(--accent);
}

.menubar-menu-trigger[data-disabled] {
  opacity: 0.5;
}

• One open at a time. Opening trigger B while A is open implicitly closes A and opens B with its first item focused. The exception is a hover-switch, which leaves focus on B's trigger (see below).
• First open is intentional, subsequent are hover. While no menu is open, hovering a trigger does not auto-open, and keyboard focus alone never opens a menu. After the user opens any menu via click / keyboard, hovering a sibling trigger opens it instantly (no delay). Hover is mouse-only: touch and pen never hover, so a tap on a sibling trigger switches menus through its click instead of opening on pointerenter and then closing on the click that follows.
• Hover-switch parks focus on the hovered trigger. Switching menus by hover is a full close/open cycle: the outgoing menu unmounts, so the focus it held has to be relocated or it would fall to <body>. It is relocated to the hovered trigger, not into the menu that just opened. This matches the APG reference implementation's menubar-navigation.js, whose onMenuitemPointerover focuses the hovered bar item and only then swaps the popups. So a mouse user sweeping across the bar to read the menus never has focus dragged through each popup in turn, and (autoFocusOnOpen) does not fire for the incoming surface: there is no focus move to veto. Keyboard handoff is seamless from there: ArrowDown / ArrowUp / Enter on the hovered trigger move focus to the first / last item of the menu that is already open, and moving along the bar (ArrowLeft / ArrowRight, Home / End, typeahead) switches the open menu to whichever trigger takes focus, so the expanded trigger is always the focused one. Every other open path (click, Enter / Space, ArrowDown / ArrowUp, cross-menu ArrowLeft / ArrowRight) still focuses an item inside the menu. This is a different mechanism from [forMenuSub], whose hover-open simply suppresses the focus move: a submenu opens alongside the menu that holds focus, whereas a menubar hover-switch destroys the focus holder and so must put focus somewhere.
• Hover-leave does not dismiss. Moving the pointer off the bar (or off the open menu) leaves the menu open. The APG Menubar pattern prescribes no hover-leave close, and a menubar menu always holds focus while open. Dismissing it because the mouse wandered would rip focus out from under a keyboard user and strand it on <body>. Dismiss with Escape, an outside pointer interaction, Tab, or by activating an item.
• Dismissal. Escape and an outside pointer interaction close the open menu when dismissible is true (default). [dismissible]="false" suppresses both.
• Roving tabindex. Only one trigger is in the tab sequence at a time: the open trigger, the most-recently-focused trigger, or the first enabled one when nothing's focused.
• Mount equals open. In the canonical shape each menu's [forMenuContent] is wrapped in @if (value() === '<id>'), so animate.enter / animate.leave fire on mount / unmount. The directive never toggles [hidden]. A surface kept mounted (see Mount shapes) runs no mount-cycle animation.
• Disabled triggers stay focusable (per APG). They still reflect data-disabled="" and aria-disabled="true" and are skipped by ArrowLeft / ArrowRight, typeahead, and cross-menu nav.

Subclass the root and re-provide FOR_MENUBAR_CONTEXT with useExisting pointing at the subclass, since Angular does not inherit a directive's providers; Wrapping non-form roots walks the pattern.