Bug report

Current behavior

When opening a base ui Dialog from another non-base ui modal overlay, it is possible that the page's scroll ends up in an unrecoverable locked state:

For example, Ariakit Menu adds a delay to its "scroll lock cleanup" to wait for animations/transitions, which causes the following bug:

• Menu opens and sets overflow: hidden on the page
• Menu item is clicked — Menu starts closing, but delays its scroll-lock cleanup to respect the animation
• Dialog opens before the Menu's scroll lock cleanup has happened. It snapshots the situation (eg page is scroll-locked), then applies its own scroll lock logic, which wrongly restores page scrolling while dialog is opened
• When the Dialog closes, it restores the previous snapshot and the page stays scoll-locked

So far, I managed to avoid the issue with a couple of workarounds:

• trick ariakit by moving the animation on child of the popup element, so that ariakit executes scroll lock cleanup without any delays;
• manually prevent scroll lock on the Ariakit Menu (not ideal, but seems to work);

Although I wonder if base UI could make improvemens on their side to improve scroll-lock handoff

Expected behavior

I wish base ui could coordinate cross-library scroll-lock handovers.

A few ideas:

• Come up with a robust heuristic for better coordination/restoration. For example:
  • it should not be possible for Dialog's scroll-lock logic to enable page scroll when opening;
  • it should not be possible for Dialog's scroll-lock cleanup logic to scroll-lock the page (ie add overflow: hidden) when closing
• expose a pluggable scroll-lock manager and/or explicit interop hooks

Reproducible example

https://stackblitz.com/edit/vitejs-vite-altbnksf?file=src%2FApp.tsx,src%2Findex.css

Base UI version

1.4

Which browser are you using?

Chrome

Which OS are you using?

Mac OS

Which assistive tech are you using (if applicable)?

N/A

Additional context

N/A