Dialog: mouse clicks can't focus inputs (overlay pointerdown.preventDefault suppresses mousedown)

[netchampfaris]

Summary

In a Dialog, mouse clicks cannot focus text inputs/textareas/contenteditable. Keyboard Tab + typing works, and click-driven controls (Close/Submit buttons) work — only fields that rely on mouse focus are dead. Observed on the v1/espresso-tokens branch.

Root cause

Dialog.vue uses the scrollable layout where <DialogContent> is nested inside a scrollable <DialogOverlay> (overflow-y-auto) — the standard pattern for tall, scrollable dialogs.

However, the overlay element ends up with a pointerdown handler bound through Vue's .prevent modifier (confirmed live: the canceling listener's currentTarget is the overlay div, owner Primitive). Because content is nested under the overlay, a pointerdown on a dialog input bubbles up to the overlay and is preventDefault()'d.

Per the Pointer Events spec, cancelling pointerdown suppresses the compatibility mousedown — and mousedown's default action is what focuses an input + places the caret. Net effect:

• pointerdown and click fire on the input, but mousedown and focusin never do.
• Inputs/textareas/contenteditable can't be focused by mouse.
• Buttons still work because they act on click.

Note: reproduces only with a trusted (real) mouse event. Synthetic el.click() / dispatchEvent bypasses the focus-on-mousedown machinery and will not reproduce it.

Open question

I could not locate where the overlay's pointerdown.prevent is bound — it is not in Dialog.vue's template, nor anywhere in reka-ui's Dialog/* source. It arrives on the overlay element via the $attrs forwarding chain (DialogOverlay → DialogOverlayImpl → Primitive). Tracking down and removing it at the source is the proper fix.

Current workaround (shipped)

@pointerdown.stop on <DialogContent> so content pointerdowns never reach the overlay's prevent handler. Verified: input focus, typing, Escape, buttons, and outside-click dismiss all work (reka's dismiss detection is capture-phase, unaffected by a bubble-phase .stop).

Proper fix options

1. Find and remove/scope the stray pointerdown.prevent on the overlay (ideal — root cause).
2. Keep the workaround @pointerdown.stop.
3. Restructure to reka's centered sibling layout (DialogOverlay/DialogContent as siblings, content fixed-centered) — note this trades away in-overlay scrolling for tall dialogs, and a naive sibling scroll-wrapper would render even when closed (DialogPortal is a bare Teleport), so it needs its own Presence gating.

🤖 Generated with Claude Code

[barista-for-frappe]

Confirmed bug, and the self-diagnosis matches reka-ui's architecture. A lead on the open question (where the overlay's pointerdown.prevent originates):

• It's almost certainly not in reka's Dialog/* — hence the empty search. Modal pointer-suppression lives in reka's DismissableLayer (its own directory) plus the scroll-lock helpers, which DialogContentImpl activates via disableOutsidePointerEvents on the modal variant.
• With disableOutsidePointerEvents on, DismissableLayer cancels pointerdown on anything outside the content layer. Since DialogContent is nested inside the scrollable overlay here, an input's pointerdown bubbles to the overlay and gets canceled, suppressing the compat mousedown (no focus/caret). Buttons survive because they act on click. Lines up exactly with the report.
• So this is a structural consequence of the nested-overlay (scrollable) layout, not a stray handler in our template.

On the fix: option 2 (@pointerdown.stop on <DialogContent>) is the pragmatic call — it stops the bubble before reka's outside-pointer logic sees it, and reka's dismiss detection is capture-phase so outside-click dismiss still works. Option 1 isn't actionable without patching reka. Option 3 regains correctness but loses in-overlay scrolling, as noted.

Worth a regression test in Dialog.cy.ts driving a real (trusted) mouse focus on an input — synthetic clicks won't catch it.

_{barista · claude-opus-4-8 · 8.8k in / 9.7k out · 1730k cached · 142s · $0.840}