`react-aria-components`: `Modal` reopens after navigation when using `RouterProvider` with Next.js and `Tailwind Typography` in production (Chrome only)

[teo-goulois]

Provide a general summary of the issue here

When using RouterProvider from react-aria-components in a Next.js app, a modal in the shared navbar reopens after navigation if the destination page contains a Tailwind Typography prose element.

This happens even though the modal state is closed in the navbar.
The bug only occurs:

• in production builds
• in Chrome
• when RouterProvider is used

Sometimes in development, or when not using RouterProvider, the issue does not occur.

🤔 Expected Behavior?

After navigation, the modal should stay closed since the navbar state remains false.

😯 Current Behavior

• On Chrome (production build, mostly), the modal reopens automatically after navigating to a page containing prose styles.
• The internal state in the navbar remains false.
• No error messages are shown.

🔗 Online reproduction: https://teo-bug-modal.q1xahd.easypanel.host
📦 Repo reproduction: https://github.com/teo-goulois/bug-modal-with-tailwindcss-typography-and-rac

💁 Possible Solution

Not sure yet — the issue seems related to the interaction between RouterProvider navigation handling and Tailwind Typography’s prose styles in production. It could be causing an unexpected re-render or focus/overlay trigger.

🔦 Context

I’m trying to use a shared navbar modal for navigation in my Next.js app. This bug breaks the UX because the modal immediately reopens after redirecting to some pages, even though I expect it to stay closed.

🖥️ Steps to Reproduce

1. Clone the repo: bug-modal-with-tailwindcss-typography-and-rac
2. Run npm run build && npm start
3. Open the navbar modal and click a navigation link
4. Navigate to a page containing <div className="prose">...</div>
5. Observe that the modal reopens automatically

Or test directly with the online reproduction:
👉 https://teo-bug-modal.q1xahd.easypanel.host

Version

"react-aria-components": "^1.10.1"

What browsers are you seeing the problem on?

Chrome

If other, please specify.

No response

What operating system are you using?

macOS

🧢 Your Company/Team

Lumy

🕷 Tracking Issue

No response

[snowystinger]

Thanks for the issue.
I'm not sure what this has to do with prose or tailwind, that's just css, so shouldn't cause rerenders? are you able to simplify it at all to exclude tailwind?

[teo-goulois]

Thanks for the quick response 🙏

I agree it seems like prose/Tailwind shouldn’t be related, but in my testing I wasn’t able to simplify the reproduction any further — it took me quite a while to reach the current minimal setup. Every time I try to strip out more (like removing prose), the bug disappears.

What makes it even stranger is:

• Everything works fine in Firefox (only Chrome production build is affected)
• The modal state is still false, but somehow the modal reopens anyway

So I can’t confidently say Tailwind is the root cause, but it looks like it’s at least part of the conditions needed to trigger the issue.

[teo-goulois]

CleanShot.2025-08-29.at.09.05.07.mp4

I was able to reproduce this in development mode as well, but it’s not consistent — sometimes the bug doesn’t happen in dev.

Some extra observations:

• If I navigate to a page that has the prose class, the modal bug appears.
• After that, even if I reload on a prose page and then navigate to a page without prose, the modal still reopens incorrectly.
• If I only navigate between pages without prose, everything works fine.
• I also have a test page (page 3) that uses a custom class with similar styles to prose but not using Tailwind Typography — on that page, navigation works correctly.

[teo-goulois]

I’ve updated the code to make the reproduction clearer.
You can now try it directly here:
👉 https://teo-bug-modal.q1xahd.easypanel.host

This version should make it easier to see how navigating to a page with prose triggers the issue.

[snowystinger]

I know Chrome does try to do some dom state management so that if you navigate "back" to a page, it'll be in the expected state. I do not know much about this process, nor about how Next handles navigation.

You said the internal state in the navbar remains false. Can you check the internal state value of the components in node_modules as well? Maybe if our components say "true" then we can follow where ever that's coming from.

One thing that stands out to me, I see you're using useDisclosure? https://github.com/teo-goulois/bug-modal-with-tailwindcss-typography-and-rac/blob/a8f6c73eed1a39e11135b5cf08ea2171ec2a18ff/src/components/shared/shared-navbar.tsx#L15C9-L15C24 this might be a red herring, but why? It looks like you're just wanting a boolean state for open/closed that responds to press events? useDisclosure will do more than that, particularly in Chrome which supports onBeforeMatch

react-spectrum/packages/@react-aria/disclosure/src/useDisclosure.ts

Line 51 in e717ee9

let supportsBeforeMatch = !isSSR && 'onbeforematch' in document.body;

so I wonder if this is matching and causing that state to actually flip to open internally.

[teo-goulois]

I removed all the useDisclosure usage just to be sure, but it didn’t change anything. I also checked in the React Profiler/DevTools — my own navbar state is always correct (it stays false), even when the modal reopens. Here’s a capture of that:
https://github.com/user-attachments/assets/a1d1393e-f784-4bae-8836-847e59beb88e

I’m honestly not sure how to check the internal state of the RAC components inside node_modules. If you can point me to where exactly I should look or log, I’m happy to try.

What still bothers me is that everything works fine until I add the prose class from Tailwind Typography. As soon as that’s in, the bug appears. A custom class with similar styles doesn’t trigger it. So maybe this isn’t really a RAC issue, but some weird interaction with the CSS + Chrome + navigation?

[snowystinger]

I just meant putting a breakpoint or console log in node_modules around this line to start

react-spectrum/packages/react-aria-components/src/Modal.tsx

Line 84 in 2247a51

isOpen,

to see if the component actually thinks it is open.

Depending on what you find there, you can chase it either up towards the app or down towards the hooks.