Modal: have an option to keep multiple non-nested modals open

[sandymcfadden]

What problem does this address?

In #51602 it seems this change made it not possible to have multiple modals open if they are not nested within each other.

We use WordPress components in a project outside of WordPress, the Day One Web Client, and have built our own modal handling infrastructure to open and close modals using a global modal state. We end up having multiple modals open that are not nested in each other, and with this when one closes they all close and that is not our intention.

What is your proposed solution?

It would be great to have a way to opt out of this behavior, maybe with a boolean prop on the Modal component.

[mirka]

Just to understand better — in your use case, are the modals "nested" from standpoint of the user, in which case they can technically be rearchitected to render in a nested way as well? Or are they totally unrelated modals, for example you have a modal open to change the username but then a modal advertisement pops up above it.

[sandymcfadden]

Hi @mirka and thanks. At least most would be seen as related to the user and only appear after some user action. I can't think of any right off that wouldn't be that case.
The system we have in place to manage them works pretty well except for this issue. One of the things we do is have many of our modals be URL accessible so we may open a modal based on user action, or navigation.

[mirka]

Thanks, I wanted to gauge how pervasive/necessary that architecture might be in the ecosystem. I don't think we can make it an opt out like you suggest, because the new behavior is a side effect of a bug fix, rather than a nice-to-have feature.

@stokesman may have a better idea of whether we can maintain the bug fix in #51602 while still allowing multiple non-nested modals to be open.

[stokesman]

…whether we can maintain the bug fix in #51602 while still allowing multiple non-nested modals to be open.

I think it probably could be allowed without regressing anything else and yet it’s really not new behavior. Even before #51602, opening a non-nested modal would close the current one. The implementation details did change and I suppose the previous way had more potential for exceptions. An example in Gutenberg is having the preferences modal open and then using a keyboard shortcut to open the command palette. A unit test covering such was added in #54569.

We might be able to come up with some way to allow opting out yet I question whether it’s a good idea.

[ciampo]

A good compromise could be to remove the code that forces non-nested modals to close, while leaving the code that ensures that only the latest modal is accessible by assistive technology (and has focus trapped).

That way, we may still be providing an accessible solution out of the box. Consumers of the component that would like to have the "close previous modal when opening a new one" behaviour may still add it by orchestrating modals in their code.

I guess we should first investigate if my assumption about that being an accessible solution is true (it seems so, by looking at the docs) cc @andrewhayward