[Dialog, Popover, Menu, Select, PreviewCard] Unify backdrop implementation

[michaldudak]

Unified and simplified backdrop implementation:

• removed inline styles
• set role: 'presentation' in all backdrops
• removed use*Backdrop hooks
• added an internal backdrop (FloatingOverlay) for modal dialogs and alert dialogs to block pointer interaction
• added the container prop to DialogBackdrop and AlertDialogBackdrop
• added the MenuBackdrop

part of #623

[mui-bot]

Netlify deploy preview

https://deploy-preview-841--base-ui.netlify.app/

Generated by 🚫 dangerJS against 7f6be6a

[atomiks]

Menu didn't have a Backdrop in the first place, but should?

[michaldudak]

Added.

[atomiks]

What about z-index?

[michaldudak]

Yeah, right, this is going to be tricky. We could figure out the z-index of the popup and set this one lower, but this will be unreliable in some cases. We might have to expose the className of this part, or the whole part itself, to be consistent with the rest of the API.

[vladmoroz]

Is this another problem solved by a separate Portal part? 😅

[michaldudak]

Not really, unless I'm missing something. Having an explicit Portal wouldn't help determining the right z-index of the internal backdrop.
Perhaps a better solution is not rendering the internal backdrop, but adding the inert attribute to all elements except the popup?

[atomiks]

Perhaps a better solution is not rendering the internal backdrop, but adding the inert attribute to all elements except the popup?

This could work. guards={false} on FloatingFocusManager does this, but it allows escaping to the browser address bar of course, which we didn't want to allow. Guess this is relevant: floating-ui/floating-ui#3098

The other option is to get the computed z-index style of the Popup and apply the z-index to be just one less on FloatingOverlay?

[michaldudak]

This could work. guards={false} on FloatingFocusManager does this, but it allows escaping to the browser address bar of course, which we didn't want to allow.

I'll take a look at Floating UI implementation and see what I can do, then (floating-ui/floating-ui#3131)

The other option is to get the computed z-index style of the Popup and apply the z-index to be just one less on FloatingOverlay?

This was my first idea, but I realized someone might style a child of the popup for some reason. Or the z-index could change depending on how many dialogs are open, so this might not be the most reliable solution.

[atomiks]

Is the bug that causes the Backdrop to be inserted into the DOM after the Popup fixed with this? Not sure why it would occur exactly but I'm assuming the way FloatingPortal creates a root container could be an issue. There is one minor part that has asynchronicity related to cleanup, but not sure if that would be the cause.

[michaldudak]

I don't know TBH. I could reproduce it neither on master nor here.
@vladmoroz, do you have a reliable repro?

[vladmoroz]

I don't know TBH. I could reproduce it neither on master nor here.
@vladmoroz, do you have a reliable repro?

If its about Backdrop overlaying the Popup, I think I had a transition on the Popup, and no transition on the Backdrop

[atomiks]

If its about Backdrop overlaying the Popup, I think I had a transition on the Popup, and no transition on the Backdrop

I was able to reproduce it consistently (once every ~5-10 times) on master previously when clicking very quickly on the trigger and backdrop - the backdrop did have a normal transition along with the popup. But on latest master, and this PR on the new dialog page, I haven't been able to reproduce it at all. Might be fixed?