Fix: plain inputs unfocusable on click in scroll dialogs#84
Merged
Conversation
DialogScrollContent nests the content inside DialogOverlay (so the backdrop can scroll), unlike the standard DialogContent where the two are siblings. reka's DialogOverlay registers `@pointerdown.left.prevent`, so a pointerdown on a plain <input> bubbles to the overlay and gets its default prevented. That suppresses the compatibility mousedown event, which is what natively focuses an input — so clicking the field did nothing while clicking the label (native `for=`) still worked. Stop pointerdown propagation at the content so it never reaches the overlay handler. Outside-click dismissal is unaffected: it keys off the pointerdown target being outside the content, not on bubbling through it. Affected the Designation field in the applicant OfficeFormDialog (the only plain text input there); the fix lives in the shared primitive so it repairs every scroll dialog containing a plain input. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Adds a Playwright regression test that opens the applicant Office dialog and asserts a real click on the plain Designation <input> focuses it, that typing flows through, and that backdrop-click dismissal still works. Verified as a genuine guard: removing the @pointerdown.stop fix makes the toBeFocused assertion fail. The dismissal check runs on a freshly-opened dialog because reka absorbs the first outside pointerdown once focus has entered a text input (pre-existing modal behaviour, unrelated to the fix). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The Designation field in the applicant Office dialog couldn't be focused by clicking it — only clicking its
<label>worked.Root cause
reka-ui's
DialogOverlayregisters@pointerdown.left.preventon the overlay element. TheDialogScrollContentvariant nests the dialog content inside that overlay (so the backdrop can scroll), unlike the standardDialogContentwhere overlay and content are siblings. As a result, apointerdownon a plain<input>bubbles up to the overlay and getspreventDefault()— which suppresses the compatibilitymousedownevent that natively focuses inputs.Clicking the label still worked because that uses the native
for=association. reka triggers (Select, DatePicker, HelpTip) are unaffected because they manage their own focus onpointerdown; only plain text inputs rely on the suppressed native behaviour — which is why only the Designation field (the lone plain input) was broken.Fix
Add
@pointerdown.stopon theDialogContentinDialogScrollContent.vueso an input'spointerdownnever reaches the overlay's prevent handler. Outside-click dismissal is unaffected (reka keys off the pointerdown target being outside the content, not on bubbling through it). The fix lives in the shared primitive, so it repairs every scroll dialog containing a plain input.App-wide audit
Reviewed all forms/fields/overlays. No other instances of this bug class exist: every other dialog/sheet uses the sibling-overlay pattern (immune), all menus/popovers are floating + portaled (immune), and there are no custom focus-stealing overlays.
DialogScrollContentis used in 4 places butOfficeFormDialogwas the only one with a plain input inside (the others are read-only detail views) — all covered by this shared fix.Tests
Adds
app/tests/e2e/office-dialog-focus.spec.ts— opens the Office dialog and asserts a real click focuses the Designation input, typing works, and backdrop-click still dismisses. Verified as a genuine guard: removing the fix makes thetoBeFocusedassertion fail.🤖 Generated with Claude Code