Michał Dudak

@aarongarciah, @mnajdova, what's the status of moving @mui/base components to Material UI? Do you still want to accept PRs to @mui/base?

The proposed change makes sense, although I'm pretty sure we will find developers who relied on the old behavior. I'm not really keen on introducing a prop to configure this....

Based on our discussions, we agreed to drop the `import * as Foo` pattern and replace it with `import { Foo }`, so it's easier to type and VSCode suggestions...

Both Popup and Backdrop are portaled, so they are rendered differently than defined in source code. No matter what you wrap around the Popup, it won't end up being around...

Since we added the Portal as an explicit part, this is no longer an issue.

TBH I'd just drop it. The `checkVisibility` function was introduced only last year in Safari, so this would lead to inconsistent results between browsers. Also, `checkVisibility` returns `false` when an...

IMO what we have currently is OK and I don't see a problem with readability. The proposed solution introduces an additional `useMemo` call, that can have a slight perf impact.

Likely the only time we need to return a function is when anything below uses `useButton` as merging its props requires access to other external props (i.e. the `onKeyDown` prop...

> One with no default theme or callback function, imported from @material-ui/unstyled It seems to me that the System could be a better place for this as it's a utility...

We don't have access to the DOM node on the server (as it doesn't exist there), so it's impossible to measure its height. I can't really think of another fix...