Context menu

Problem Context

• A file, row, canvas object, map item, text selection, card, or selected set has several commands that are useful but not always worth visible space.
• Users may invoke commands through right click, secondary click, long press, context-menu key, Shift+F10, or another platform-specific request.
• The target object, selected set, pointer location, permission state, and object state determine which commands are available.
• Important commands still need visible or documented access because context menus are secondary and less discoverable.

Selection Rules

• Choose context menu when commands are specific to the object, selection, or location where the user invoked the menu.
• Use action menu when the main work is designing the command taxonomy, grouping, disabled reasons, destructive handoff, and scope labels independent of invocation method.
• Use menu button when users need a visible named trigger for the same short command list.
• Use popover when the anchored layer needs contextual information, controls, or light editing instead of menuitem command activation.
• Use visible buttons for primary, frequent, safety-critical, or onboarding commands that users should not have to discover through secondary invocation.
• Use command palette when commands are product-wide, searchable, shortcut-driven, or not tied to the current object.
• Use native browser or platform context menu when the product does not need custom object-specific commands.
• Use a confirmation dialog, undo, or review flow after high-risk context-menu commands rather than running them silently.

Required States

• Resting object or selection state before invocation.
• Pointer-invoked open state anchored to the object or pointer coordinate.
• Keyboard-invoked open state anchored to the focused object or selection, not stale pointer coordinates.
• Visible target state showing which object or selected set commands will affect.
• Menu focus state with active item, Arrow key movement, Enter or Space activation, and Escape dismissal.
• Disabled or unavailable item state with reason when the user can recover.
• Destructive item state separated from safe commands and routed to review or recovery.
• Dismissed state that returns focus to the invoking object or selected set.
• Target changed or selection changed state that closes or recalculates the command set.
• Touch or long-press state with equivalent command availability where the platform supports it.

Interaction Contract

• The menu opens only for the object, selection, or location that invoked it.
• Pointer and keyboard invocation expose the same applicable commands for the same target.
• The invoked target remains highlighted, focused, or otherwise visibly identified while the menu is open.
• Opening moves focus into the menu or sets an active descendant so Arrow keys operate inside the command list.
• Escape, outside click, scroll away, or target removal closes the menu without running a command.
• Safe activation closes the menu and reports what happened to the target.
• High-risk activation moves to confirmation, undo, restore, or review with the affected target named.
• Focus returns to the invoking target or a logical replacement after dismissal or activation.
• The context menu is not the only route to important commands.
• The menu content stays command-like and does not contain forms, pickers, embedded editors, or long explanatory panels.

Implementation Checklist

• Define which objects or selections can invoke a context menu and which commands apply to each state.
• Handle pointer secondary-click, keyboard context-menu key, Shift+F10, and touch or long-press where supported.
• Anchor pointer menus to the invoked object or pointer and keyboard menus to the focused target.
• Keep the target visibly selected or focused while the menu is open.
• Use menu roles and menuitem semantics only when implementing full menu keyboard behavior.
• Implement Arrow keys, Home, End, typeahead when useful, Enter, Space, Escape, outside dismissal, and focus return.
• Recalculate or close the menu if selection, target state, permission, or viewport position changes.
• Expose unavailable commands with reasons when users can act on the reason.
• Keep primary commands visible elsewhere and document advanced shortcuts where appropriate.
• Test repeated rows, stale selection, keyboard invocation placement, touch invocation, zoom, clipping, portal placement, screen readers, and destructive handoff.

Common Generated-UI Mistakes

• Making right click or long press the only way to discover important commands.
• Opening a context menu for the wrong row because selection and pointer target are out of sync.
• Ignoring keyboard context-menu invocation or placing the menu at a stale pointer coordinate.
• Showing different command sets for right click and Shift+F10 on the same object.
• Using a context menu as a catch-all for global navigation, filters, forms, previews, and settings.
• Running destructive commands immediately from the menu without confirmation, undo, or object-specific review.
• Leaving focus behind the menu so Arrow keys scroll the page or move the selected object.
• Letting menus remain open after the target disappears, scrolls away, or changes state.

Critique Questions

• What exact object, selection, or location invoked this context menu?
• Can users access the same important command through a visible route?
• Does keyboard invocation open at the focused object with the same eligible commands as pointer invocation?
• How are stale selection, target removal, viewport collision, and scroll handled?
• Are commands scoped, labelled, grouped, disabled, and risk-separated according to action-menu rules?
• Where does focus go on open, Arrow navigation, Escape, outside click, safe activation, and destructive handoff?