Skip to content

fix(responsive-dropdown): keep dropdown open when window loses focus#136

Merged
yahyafakhroji merged 1 commit into
mainfrom
fix/responsive-dropdown-file-dialog-close
Jul 2, 2026
Merged

fix(responsive-dropdown): keep dropdown open when window loses focus#136
yahyafakhroji merged 1 commit into
mainfrom
fix/responsive-dropdown-file-dialog-close

Conversation

@yahyafakhroji

Copy link
Copy Markdown
Contributor

Summary

@radix-ui/react-menu ≥2.1.17 registers a window blur listener that closes any open menu. Opening the native file picker (or switching apps to drag a file in) blurs the window, so DropdownMenu-based ResponsiveDropdown content unmounted before the file selection ever landed — silently breaking the DNS record import dropzone in cloud-portal (no dialog, no error, no processing).

Fix

Swap the desktop variant of ResponsiveDropdown from Radix DropdownMenu to Radix Popover:

  • Same anchored dropdown UX, alignment, and modal behavior; contentClassName / onCloseAutoFocus pass through unchanged.
  • Popover has no blur-close behavior (verified in @radix-ui/react-popover 1.1.15).
  • Correct a11y fit: every consumer (MoreActions, DataTable row-actions, task-queue-dropdown, cloud-portal notification dropdown + DNS import) renders plain buttons/divs — none use DropdownMenuItem, so nothing depended on menu semantics.
  • PopoverContent gets menu-parity sizing (w-auto min-w-[8rem] p-0, available-height max) so existing layouts are unaffected.

Tests

  • New regression test: dispatching blur on window while open must NOT call onOpenChange(false). Red against the old DropdownMenu implementation (with react-menu 2.1.18), green with Popover.
  • Full suite: 894/894 passing; typecheck, lint, build clean.
  • Changeset included (patch).

@radix-ui/react-menu >=2.1.17 registers a window blur listener that closes
any open menu. Opening the native file picker (or switching apps to drag a
file in) blurs the window, so DropdownMenu-based ResponsiveDropdown content
unmounted before the file selection ever landed — silently breaking the DNS
record import dropzone in cloud-portal.

Swap the desktop variant to a Radix Popover: same anchored dropdown UX and
modality, no blur-close behavior, and dialog semantics fit the arbitrary
interactive children this component hosts (none of its consumers render
DropdownMenuItem).

Adds a regression test asserting the dropdown stays open on window blur.
@yahyafakhroji yahyafakhroji requested a review from a team July 2, 2026 07:34
@yahyafakhroji yahyafakhroji merged commit 63982f9 into main Jul 2, 2026
8 checks passed
@yahyafakhroji yahyafakhroji deleted the fix/responsive-dropdown-file-dialog-close branch July 2, 2026 07:36
mattdjenkinson added a commit to datum-cloud/cloud-portal that referenced this pull request Jul 6, 2026
…ose (#1329)

## Problem

Importing a BIND zone file on the DNS records page did nothing — no
preview dialog, no error, no processing.

Root cause: `@radix-ui/react-menu` ≥2.1.17 (pulled in by #1321) closes
any open menu on **window blur**. The import dropzone lives inside
`ResponsiveDropdown` (a Radix DropdownMenu on desktop), so clicking
**Select a file** (native picker) or dragging a file in from Finder
blurred the window, closed the dropdown, and unmounted the dropzone
before `onDrop` fired.

## Fix

- **Bump `@datum-cloud/datum-ui` to ^1.3.2** — `ResponsiveDropdown`
renders a Radix Popover on desktop (same UX, no blur-close). Upstream:
datum-cloud/datum-ui#136.
- `handleDrop` reports whether the preview opened; the dropdown only
closes on success so parse errors stay visible.
- Empty accepted-file drops show an error instead of failing silently.

## Test plan

- [ ] Import via file picker — dropdown stays open while the picker is
up, preview dialog opens with parsed records
- [ ] Import via drag-and-drop from Finder
- [ ] Invalid file → error shown inside the dropdown; Export still works

## Note

The E2E regression checks are red due to a **separate, pre-existing**
control-plane change (org creation now requires a system-assigned
`generateName`; `createStandardOrg` fails with 422). It's unrelated to
this PR and affects `main` too — tracked/fixed separately.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants