Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Ensure anchored components are properly stacked on top of
Dialog
co…
…mponents (#3111) * ensure `Dialog` knows about `Modal`s via the `StackProvider` When you render a `Listbox` in a `Dialog`, then clicking outside of the `Listbox` will only close the `Listbox` and not the `Dialog`. This is because the `Listbox` is rendered _inside_ the `Dialog`, and the `useOutsideClick` hook will prevent the event from propagating to the `Dialog` therefore it stays open. Then, if you add the `anchor` prop to the `ListboxOptions` then a few things will happen: 1. We will render the `ListboxOptions` in a `Modal`, which portals the component to the end of the `body` (aka, it won't be in the `Dialog` anymore). 2. The `anchor` prop, will use Floating UI to position the element correctly. If you now click outside of the open `Listbox`, then the `Dialog` will receive the click event (because it is rendered somewhere else in the DOM) and therefore the `Listbox` **and** the `Dialog` will close. The `Dialog` also uses a `StackProvider` to know if it is the top-level `Dialog` or not. The problem is that the `Modal` doesn't use that `StackProvider` to tell the `Dialog` that something is stacked on top of the current `Dialog`. That's what this commit fixes, the `Modal` will now use a `StackProvider` to tell the `Dialog` that it's not the top-most element anymore so it shouldn't enable the `useOutsideClick` behavior. That said, this is one of the things that will be changed in the future to make "parallel" dialogs possible. Essentially, we will track a global stack and the top-most element (last one that was "opened") will win. Then hooks such as `useOutsideClick` and `useScrollLock` will use that information to know if they should undo scroll locking for example if another element is still open. * update CHANGELOG
- Loading branch information