Context Menu

Demo & usage

More examples

When to use

• A per-row or per-cell action menu in a table, list, canvas node, or file tree, triggered by right-click.
• One menu instance shared across many rows — repopulate `items`/`groups` and call `openAt()` per target, rather than mounting a menu per row.
• For a single wrapped element with nothing else driving it, `triggerMode="contextmenu"` is simpler than wiring `openAt()` yourself.

Async states

• loading
• error
• retry

Outputs

Wire it to your API

This component is headless about transport: it renders what you give it and reports what the user asks for. Nothing below requires @styloviz/data — drive it from whatever you already use.

• This component does not emit a query, so it renders what you give it. Fetch on your own trigger and bind `items`, `loading` and `error`.
• Normalize failures with `toSvDataError()` from `@styloviz/core`. It derives `retryable` from the status, so a 404 does not get a "Try again" button that can only fail again.

Full walkthrough: Connecting to a backend.

Customization & theming

• Everything Dropdown Menu supports — items/groups, icons, descriptions, shortcuts, badges, danger items, themes and sizes — applies unchanged.
• `triggerMode="contextmenu"` disables the wrapped trigger's left-click toggle in favor of its native right-click.
• `openAt(x, y)` works regardless of `triggerMode`, for menus with no rendered trigger element at all; `openAtElement(el)` anchors to an element's live rect instead — the kebab-button path.
• `nativeMenuSelector` (opt-in) names the regions inside the trigger where the browser's own context menu wins — links, fields, prose — so suppression is narrow rather than blanket.
• `[sheetOnNarrow]="true"` turns the panel into a bottom sheet below 640px — full-bleed, rounded at the top only, padded clear of the home indicator and lifted above the virtual keyboard. At 375px an anchored panel is clamped until it covers the thing it points at, and a context menu's anchor is a cursor POINT, which is the case with the least room of all. Off by default, because it changes how an existing app looks on a phone.
• Three ways in, not one: right-click, a long press on touch (500ms, abandoned if the finger travels — a slow scroll over a right-clickable list is not a menu request), and Space or Enter from the keyboard. The keyboard path anchors the menu to the trigger rather than to a cursor, which is the APG position: there is no pointer in a keyboard interaction, and inventing one would put the menu where the user is not looking.

Best practices

• Do: Always ship an equivalent visible action path — a kebab button, a toolbar, a row action. Right-click is undiscoverable, unavailable on touch, and the keyboard routes (Shift+F10, the ContextMenu key, Enter/Space on a promoted trigger) are not something most users will guess. Open the shared menu from the kebab with `openAtElement(button)` so a keyboard user's menu appears at the button, and set `targetLabel` so it announces "Actions for Invoice 4021".
• Don't: Don't put an action ONLY in a context menu. If it is the only way to reach something, most users never reach it.
• Do: Repopulate `items`/`groups` for the clicked target before or alongside calling `openAt()`, so the menu never shows stale actions from the previous target.
• Do: Call `event.preventDefault()` in your own `(contextmenu)` handler when using `openAt()` directly, so the native browser context menu does not also appear.
• Tip: Re-anchoring is safe while the menu is already open — right-clicking a second target just moves it, no need to close first.
• Don't: Don't mount one `sv-dropdown-menu` per row for a large list — share a single instance and call `openAt()` with that row's data instead.

Accessibility

• Same `menu`/`menuitem` ARIA roles and keyboard navigation as Dropdown Menu — a context menu opened at the cursor is still fully keyboard-operable once focus reaches it.
• It can be OPENED from the keyboard, not just navigated once open: with nothing focusable projected as a trigger, the wrapper is promoted to `role="button"` with a tab stop, and both Space and Enter open the menu. Enter used to do nothing at all, so the keyboard path worked only if you guessed which of the two keys a button answers to.
• And from touch: a right-click menu has no touch path at all — there is no right button, and iOS Safari fires no `contextmenu` event for a long press on a non-selectable element — so a held touch opens it. Mouse and pen are excluded deliberately: a mouse has the right button already, and a held left press is how a drag or a text selection starts.
• ★ SET `targetLabel` TO WHAT THE ACTIONS ACT ON. Without it the panel announces itself as "Menu" and then reads "Edit, Duplicate, Delete" — every item true, and no way to tell which of forty rows they belong to. With it the panel's name becomes "Actions for Invoice 4021". A shared menu with no projected trigger (the `openAt()` / `openAtElement()` pattern) moves DOM focus into the panel on open, so that name is read as focus arrives and `aria-activedescendant` is published on the focused panel; Escape returns focus to the kebab that opened it. A promoted wrap-one-element trigger keeps focus and carries the target in its own name ("Open Actions for Invoice 4021").
• Shift+F10 and the ContextMenu key open it from the focused trigger in `contextmenu` mode — the platform-standard keyboard equivalents of a right-click.
• The native context menu is suppressed on the trigger whenever `triggerMode="contextmenu"` is set. ⚠️ Shift+right-click is NOT a reliable escape hatch: that bypass is Firefox behaviour, not Chromium or WebKit. Suppression has a real cost — copy, paste, open-in-new-tab and translate all go with it — so narrow it with `nativeMenuSelector` (e.g. `a[href], input, textarea`) and never suppress on a region whose value is those actions.