Dropdown created in a modal shows up behind the modal

[oliv-yu]

A Clay Dropdown situated in a Clay Modal will show up behind the modal. It looks like it's not nested. Our temporary fix for our local case was to change the z-index, but let us know if there's a more targeted solution.

Sandbox for reference: https://codesandbox.io/s/nostalgic-proskuriakova-6cyv4

[matuzalemsteles]

Hmm, I thought we already fixed this using Portals in DropDown, but it looks like really z-index is getting in the way. @marcoscv-work have a problem if we change DropDown's z-index to 1060?

Thanks @oliv-yu for tracking this.

[matuzalemsteles]

I had forgotten that we revert the use of z-index because it may look above Modal when the dropdown button is out of Modal. Maybe we have to think of some strategy for this in the components in React.

Maybe this can work:

• If the dropdown is inside Modal, we add .dropdown-menu as sibling of modal-dialog to prevent modal-dialog overflow from hiding part of the dropdown.

@bryceosterhaus do you have any idea about this?

[bryceosterhaus]

Hmm, this is one of the hard parts about isolating dropdowns into a portal element on the html body. Ideally a dev wouldn't have to think about "is this in a modal" and then add an extra class.

I could see us going a few different routes:

1. Move dropdown html to be inline with where the trigger is, make portals only opt-in. This would ensure the proper html priority with z-index
2. Give dropdown highest z-index priority and make sure to close any dropdowns before opening a modal.
3. Make developers responsible for adding the appropriate class for when a dropdown is in a modal. One caveat is that we would have to make sure we account for nested modals and thus nested dropdowns in modals.

TBH, not really sure which route I'd prefer, I see issues with all of them. I feel like I am probably missing something here...

[jbalsas]

Hey @bryceosterhaus, @matuzalemsteles, I haven't 100% checked this case, but based on our past experience, I think one possible approach would be to have multiple portals.

Modals should have their own portal at their body level similar to the one the root body has. With that, it should be possible to honour z-index depth while avoiding the inlining (overflow: hidden or unnecessary scrolls) issues. Would it be possible to pick the portal closest to your parent or your root automatically so developers wouldn't have to think about that either?

This is similar to how we've fixed other modal-based issues in the past. For example, when we render AlloyEditor, which has floating toolbars, we change the containerNode or sth like that so we render somewhere else other than the body.

[bryceosterhaus]

I think one possible approach would be to have multiple portals.

this is a great idea.

Would it be possible to pick the portal closest to your parent or your root automatically so developers wouldn't have to think about that either?

This seems like the best approach. Closest modal portal and then default to body if those don't exist.

[matuzalemsteles]

hey guys, this is the problem we currently have because we have several portals, Modal has its Portal and DropDown too, so I said above not to change z-index and add the dropdown-menu which is a Portal , the closest to the modal portal. Accurately, on sibling from .modal-dialog.

[jbalsas]

Hey @matuzalemsteles, seems like there might be various issues here.

• When I say multiple portals, it means multiple portals for Dropdowns. Dropdowns inside modals should use a different portal than dropdowns outside of it. With the portal bound to the modal container, depth should be preserved.
• Ideally, we should only have one portal at a given level but that might make it complicated to handle depth within it. Modals should stack above dropdowns or tooltips. For that reason, I guess having multiple portals for the various components should make it easier to stack, as we only need to control z-index on the outer portal rather than in the inner layers.

[matuzalemsteles]

Hey @jbalsas I actually think that would fix the problem, at least manually testing, we would not need to modify any z-index, we currently have multiple portals for any Dropdown and also for any Modal (ideally it will only render one ...), so dropdowns within Modal need to be rendered as modal-dialog sibling to avoid being underneath.

To further illustrate this is a DOM image of Olivia Yu's use case, and DropDowns outside Modal would continue with their own portal the order here wouldn't matter

We can preserve the dropdown within the modal tree but we would have to deal with z-index with conditional and modify only if there is a dropdown-menu within modal if we change without it we would have problems with dropdown outside of modal.

Let me know if I'm getting it wrong.

[jbalsas]

Hey @matuzalemsteles, yup, that's what I was saying. Ideally, I think we should only keep one portal per component (per stacking level), so we can stack them, for example, if our depth priority is dropdowns < popovers < tooltips < Modals, I'd expect something like:

<body>
    <div>Things</div>

    <!-- General portal for dropdowns -->
    <div class="dropodown-portal">
        <div class="dropdown-menu">...</div>
        <div class="dropdown-menu">...</div>
    </div>

    <!-- General portal for tooltips (on top of dropdowns either positionally or via z-index) -->
    <div class="tooltip-portal"></div>

    <!-- General portal for modals (on top of the rest either positionally or via z-index) -->
    <div class="modal-portal">
        <div class="modal">
            <!-- Inner portal for dropdowns -->
            <div class="dropodown-portal">...</div>
             
            <!-- Inner portal for tooltips (on top of dropdowns either positionally or via z-index) -->
            <div class="tooltip-portal">...</div>
        </div>
    </div>
</body>

I think a solution along those lines like the one you outlined should work, but we'd still have some edge cases where we might need to tweak things manually if we only rely on html precedence, so controlling layers of components might be easier in the long run. We can iterate over this, of course :)

I'm also just talking off the top of my head, without looking at how current components are setup, so you'd know best what's possible right now and what can be our best course of action.

[matuzalemsteles]

Much clearer now, thanks @jbalsas for the explanation I think we are aligned on this, I think we can go with this specific case for Modal and DropDown now and then we can think better for all the other components when we do.