Add <CommandPalette>, Add <Dialog> -- [Breaking]: <Modal> was previously aliased to <Dialog> and is now _just_ <Modal>

[NullVoxPopuli-ai-agent]

The ⌘K pattern, as a primitive: a combobox (the input) wired to a listbox (the results), optionally in a modal <dialog>.

It owns the input, the keyboard, the aria wiring, and the open state. It does not filter. The caller renders the results, in the order the caller wants, from wherever they come from — an array, a fetch, a ranked index. kolay is the motivating consumer: its new searcher already ranks pages, and needs somewhere to put them.

<CommandPalette @onSelect={{this.go}} @hotkey="mod+k" as |p|>
  <p.Trigger>Search</p.Trigger>

  <p.Dialog>
    <p.Input aria-label="Search" />
    <p.List as |l|>
      {{#each (this.filter p.query) as |r|}}
        <l.LinkItem @href={{r.path}}>{{r.title}}</l.LinkItem>
      {{/each}}
    </p.List>
  </p.Dialog>
</CommandPalette>

Dialog is optional. Leave it out and the same Input and List render inline, for a search page of its own.

What the platform does, instead of us

behavior	mechanism
top layer, focus trap, focus restore, focusing the input	<dialog> + showModal()
click outside to close	closedby="any"
Esc	native <dialog>
keyboard nav that does not move focus	aria-activedescendant
the caller's results changing	MutationObserver

No z-index, no portal, no focus-trap library, no autofocus attribute, and no document-level click listener. showModal() already focuses the first focusable element in the dialog, which is the Input.

There is no tabster mover here, deliberately: focus has to stay in the <input> or the user stops typing.

Enter dispatches a real click() on the active option, so one handler covers the mouse and the keyboard, and a LinkItem routes exactly as it would have for a mouse — ⌘-click included, which is also the one click that does not close the palette.

Two calls worth a second opinion

• closedby="any" is not yet Baseline. Where it is missing, the palette degrades to Esc-only. I did not add a JS fallback — that would put back the document click listener this is meant to delete. It is set before ...attributes, so callers can override it.
• No Invoker Commands (commandfor / command), Baseline since Dec 2025. A declarative trigger would open the dialog behind the component's back, and the toggle event on <dialog> that would fix that has thinner support than closedby does. Trigger is a plain button for now.

Tests

11 new tests in test-app, all passing: aria wiring, arrow keys, wrapping, Enter, click, pointer activation, disabled items, a changing result list, the dialog lifecycle, the hotkey, the controlled query, and LinkItem routing under setupApplicationTest.

The 4 <InViewport /> failures on this machine are pre-existing and unrelated (IntersectionObserver under headless Chrome).

Docs

New page under 5-floaty-bits, with a live demo, the async-results shape, and the keyboard table.

🤖 Generated with Claude Code

[bolt-new-by-stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[github-actions]

Project	Preview URL
Docs	https://b18d872a.ember-primitives.pages.dev

Logs

[NullVoxPopuli-ai-agent]

CI's job fails before it reaches this branch's code: spawn ember-tsc EACCES while building packages/docs-support. It is pre-existing — every PR run since at least Aug 9 fails there identically, including renovate lockfile-only PRs (example). Nothing here touches packages/docs-support.

Run locally instead: ember-primitives lint:types + lint:js clean, and test-app test:ember green except the 4 pre-existing <InViewport /> failures (IntersectionObserver under headless Chrome).

[NullVoxPopuli-ai-agent]

The CI failure I noted above is fixed in #800 (a turbo/pnpm bin race, unrelated to this branch). All 12 checks pass there, so once it lands this branch can be rebased and will get a real CI run.

One correction to my earlier note: the four <InViewport /> failures are local to my machine, not pre-existing on CI — Default Tests passes on the runner in #800.

[NullVoxPopuli]

a destructor here isn't needed. JS garbage collection handles this for us

[NullVoxPopuli-ai-agent]

That one is gone -- it was the modifier's teardown clearing the element reference, and you are right that nothing needed it.

The other registerDestructor in this file stays, and I want to flag it rather than quietly keep it. It removes a document keydown listener for @hotkey. GC cannot collect that one: document holds a strong reference to the handler, the handler holds the component, and the component outlives its own teardown for as long as the page does.

Tested it rather than argued it. With the destructor removed:

not ok - the hotkey listener goes when the palette does
  actual:   1,1
  expected: 1

A palette that has been torn down still answers ⌘K, and it stacks: every render leaves another live listener. The test is in the branch, so if the destructor is ever dropped it fails rather than leaking quietly.