Dismissable modal closes when you press a button the app removes mid-press

[thhermansen]

Provide a general summary of the issue here

In a dismissable ModalOverlay, pressing a button that the app re-renders or removes while the press is in flight can close the modal, even though the pointer never left it.

The press stops belonging to the modal. Once the pressed element is out of the modal's subtree, dialog.contains(event.target) is false and event.composedPath() no longer includes the overlay ref, so useInteractOutside reports an interaction outside and the overlay dismisses.

isValidEvent already guards against a target that has left the document, but the check is nodeContains(ownerDocument.documentElement, target), and contains is true of the root element itself. The browser reports documentElement as the target here, so the guard passes and the press is treated as a genuine press outside.

🤔 Expected Behavior

Pressing a button inside a modal does not dismiss it, even if that button is re-rendered or removed while the press is in flight.

😯 Current Behavior

The modal dismisses. Both pointerdown and click for that press arrive with documentElement as the target, the pointer does not move between them, and elementsFromPoint at that position still lists a button inside the dialog. useInteractOutside requires both events to look outside before it fires, and a press where only the click was retargeted did not dismiss, which is consistent with that.

One thing I could not explain is why the target is the root rather than a nearer ancestor. Retargeting itself is expected: a click fires on "the most specific ancestor element that contained both elements" (MDN), and the removed-target case is still being settled (w3c/pointerevents#492). But Chrome names the nearest still-connected ancestor. A button that removes itself in its own pointerdown listener gives pointerdown=BUTTON, mousedown=DIV, pointerup=DIV, mouseup=DIV and no click at all. The button's parent was still in the tree in our case, so that route would have named the parent.

Ruled out by measurement: nothing throws, the dialog's subtree is not unmounted, inert is unchanged on every body child, pointer-events is auto on html and body, there is no scrollbar gutter, and the toast region is present but does not cover the press position.

💁 Possible Solution

Is documentElement ever a legitimate outside-press target for a modal whose underlay covers the viewport? If not, rejecting it in useModalOverlay would close this without changing what the check gained in #1369, which widened it from body to documentElement so a non-modal overlay on a page with a short body stays dismissable (#1367).

The same guard shape exists elsewhere: Headless UI checks isConnected on the target for the same reason (headlessui#869, a CodeMirror editor replacing its own nodes inside a dialog). That check has the same hole, since the root is connected, so this looks like a gap in the common approach rather than something specific to react-aria.

Our workaround is shouldCloseOnInteractOutside={element => element !== element.ownerDocument.documentElement} on the ModalOverlay. It has held up across our modals and drawers.

🔦 Context

A table inside a modal, each row with an "Add" button. A press runs a mutation, and when it resolves the row re-renders and the button is swapped for a disabled "Added" one. Pressing several rows in quick succession closes the modal, so people reopen it for every row. It is a timing problem: the press has to land while an earlier mutation is resolving, so it is intermittent and hard to trigger deliberately.

🖥️ Steps to Reproduce

I do not have a minimal repro. In our app: a table inside a dismissable ModalOverlay, each row button runs an async mutation, and the row re-renders when it resolves. Press buttons in quick succession so one resolves while the next press is in flight.

Version

react-aria-components 1.20.0, @react-aria/interactions 3.27.1, @react-aria/overlays 3.31.2

What browsers are you seeing the problem on?

Chrome 151.0.7922.173 (arm64)

If other, please specify.

Investigated with AI assistance.

What operating system are you using?

macOS

[thhermansen]

Update: I spent some time trying to reproduce this outside our app.

I built a minimal page and tore it down piece by piece. What still reproduces is a dismissable HeroUI Modal, a plain HTML table, plain <button> elements, and a toast raised on each press. Our own modal wrapper, HeroUI's Table, HeroUI's Button, the button's loading state and the disabled button the row swaps to are all gone, and it kept happening after each of them.

The toast is the one thing that flips it. Remove that single call and it stops, put it back and it returns.

Rewriting the same page with react-aria-components directly, inline styles and no HeroUI, does not reproduce. Not with the toast region portaled into <body>, not animated the same way, not marked as a top layer. So something above react-aria is required and I have not isolated it.

I should also retract the cause I gave in the report. I instrumented every press and the button is not removed mid-press: pointerup for the same press still lands on it, and it is present in elementsFromPoint in every frame. Removal was my guess, not a measurement. I also ruled out an exception, an unmounted dialog, inert, pointer-events, the top layer, a scrollbar, and <body> not covering the press point.

What I think this means. There is nothing here you can run, so I am happy for this to be closed. If it belongs anywhere upstream it is probably not in useInteractOutside itself but in whatever combination of overlay and toast layer produces the press in the first place, and I cannot point at that yet.

The one thing I would still leave with you: a modal's underlay covers the viewport, so document.documentElement is not a target a user can press. Whether useInteractOutside should refuse to treat it as an outside press regardless of how it got there is your call, and it is the reasoning behind #10511.