Material-ui: [Popper] Missing z-index with Dialog

[RoiEXLab]

I have the following issue:
When I embed a Popper component in a Dialog which also contains the anchor component, the popper is rendered behind the dialog.
I created a modified version of one of examples in the popper docs to demonstrate this: https://codesandbox.io/s/8k7n9o3y69?module=%2Fdemo.js
There's a workaround to this, but I think it's ugly and the popper component should really be able to handle this on its own:
You can apply zIndex: 1400 as a style, which will force the popper to be rendered over the 1300 index of the dialog.

[oliviertassinari]

The Popper component doesn't have any style. You should be able to apply a z-index from the theme.

zIndex: theme.zIndex.modal,

[RoiEXLab]

I found that out by myself a couple of hours ago. Admittedly it's a better workaround than just setting the zIndex to what seems to be an arbitrary value.
However the popper component does support a container component, right? If instead of document.body the root component of the current dialog (if there's one) of the anchor element (or the popper element) would be the default component, this should solve the issue already if I'm not mistaken (because zIndex is relative).

[oliviertassinari]

@RoiEXLab You can use the container property to change the insertion point, but if you move it into the Dialog, you will face an overflow issue: https://codesandbox.io/s/0xo1mj4qrn.

[RoiEXLab]

Fair enough.
What's the highest component that is elevated? There should be another layer where the overlay that greys out the background is. Using this component as container shouldn't result in the overflow issue you pointed out.

If the container isn't the right prop to modify at all, would it make sense to increase the zIndex for the component by default, or simply when it detects the anchor element is nested inside a dialog?

[oliviertassinari]

What's the highest component that is elevated?

@RoiEXLab The z-index values: https://material-ui.com/customization/default-theme/?expend-path=$.zIndex

here should be another layer where the overlay that greys out the background is.

I believe it's the document body.

If the container isn't the right prop to modify at all, would it make sense to increase the zIndex for the component by default, or simply when it detects the anchor element is nested inside a dialog?

The Popper doesn't try to solve this problem. It's not a problem in its scope. The Box component: https://material-ui.com/system/positions/#z-index can save you time. I doubt we can solve it automatically without leaking.

[RoiEXLab]

Bummer.
I still find the behaviour unintuitive.
You might want to add that to the docs as well (and provide an example that provides a working workaround using theme variables) when you're convinced the component shouldn't be responsible for that (or it's simply not worth it).

[oliviertassinari]

@RoiEXLab The Popper component is an abstraction on top of popper.js. It doesn't have any hard dependency on Material-UI. It can be used by anyone. If we start introducing a z-index, the value has to come from the theme. It's a significant overhead (when not shared with multiple components).

[Manuel-Suarez-Abascal]

@oliviertassinari thanks for your solution. It helped me, but it wouldn't be better to add the possibility to include or exclude the overlay by passing a props, let's say overlay='{true}'?

[robcostello1]

I found this thread when I came across the same issue. I created a wrapper for the MUI component which looks for a parent with z-index and applies a slightly higher one to the popper.

    const [zIndex, setZIndex] = useState();
    useEffect(() => {
        const context = anchorEl.current.closest("[style*=z-index]");
        if (context) {
            setZIndex(parseInt(context.style.zIndex) + 1);
        }
    }, [refTo.current]);

    return (
        <MuiPopper 
            style={{ zIndex }} 
            // etc...
        />
    );

You'll probably need to polyfill Element.closest() for full browser compatibility.

[oliviertassinari]

@robcostello1 Thanks for sharing. Have you considered using the React context instead?