Opening a Dialog programmatically from a Dropdown Menu item freezes the UI

[gdehmlow]

Bug report

Current Behavior

This is very specific, but I want to open a Dialog programmatically by clicking on a Dropdown menu item.

Basically, body gets stuck with pointer-events: none after closing the modal.

Expected behavior

After closing the modal, body should not have pointer-events: none set.

Reproducible example

[https://codesandbox.io/p/devbox/condescending-thunder-fdtprf](Codesandbox Repro)

Suggested solution

My solution was delaying the opening of the modal to the next cycle via setTimeout(() => { setOpen(true); }, 0);, but this feels kind of kludgy.

The issue probably has to do with two conflicting underlying DismissableLayers messing with each other, esp. with regards to originalBodyPointerEvents. My guess is that when Dialog mounts, because of DropdownMenu not having its cleanup effect run, body still has pointer-events: none set, so that's what Dialog thinks is the proper originalBodyPointerEvents. When the Dialog unmounts.. it "resets" to that value - pointer-events: none.

I know this is an edge case, and I'm not sure if there is actually a robust solution to this besides just manually handling it the way I did (besides having some sort of system to maintain a "stack" of pointer-event values, which would probably require wrapping the components in a wrapper context... bleh).

But I thought I would just throw this out there in case someone has a better idea.

[FredrikMWold]

When you are using components that uses an overlay such as dropdown or dialog.
You need to keep there versions in sync. They apparently end up using different versions of a the browser api. That causes some conflicts.

Make sure to sync the versions of dialog and dropdown that you have to x.x.4

[kmelon55]

I was trying to open a sheet in a select in shadcn/ui - they are components made with select and dialog in radix-ui and I had exactly the same problem.

I followed @FredrikMWold's solution to make everything in radix-ui up to date and it works!

[brunouber]

We have the same problem.
We use latest versions of both packages, that at the moment are:

• @radix-ui/react-dropdown-menu 2.1.4
• @radix-ui/react-dialog 1.1.4

We still can reproduce the issue.
As temp workaround we postponed the moment the dialog gets opened (so that it doesn't save pointer-events: none as original value)… but it would be nice to not have to do that.

[rszalski]

Just adding a datapoint here. I have multiple projects in which this has happened. In some, upgrading & aligning versions of @radix-ui/* packages worked. In others, I had to resort to using workarounds such as clearing style.pointerEvents = "" when .e.g clicking a link in a Sidebar. It seems like this happens every time a sidebar (or other overlay, such as that of a modal) is opened and then not closed before a link is clicked and causes the browser to navigate to a new route. The pointer events "none" stay applied in this case.

[etodanik]

Experiencing the same with latest radix-ui components. (I'm only using dropdown menu and scroll area anyway. Also seeing pointer events none applied permanently.

[FredrikMWold]

If just updating did not help. Then I recommend deleting node_modules and reinstalling.
I have had problems with upgrading radix before especially scroll area.