Enterprise: Modals: Allow for some modals being opened above other modals

[SofiK]

Is your feature request related to a problem or use case? Please describe.
We have noticed that with the new modals when a modal is opened within another modal the first modal is temporary closed. This seems to work pretty well but gets a little weird when it comes to messages, such as confirm messages.

Describe the solution you'd like
Our request is to add the possibility to open some modals above others, especially message modals but if possible also other modals (for cases where it just looks weird or becomes to much hide/show ). Perhaps there could be an option parameter to keep below modal in background or something?

Describe alternatives you've considered
I've also considered if the approach to not hide the "base" modal should always be used for message modals, but I think it's better if there is an option for it.

I have also considered having the option parameter to keep in background on the "base modal", but in some cases both alternatives might need to be used within the same modal which I guess would not work with that approach.

Additional context
-

And what application do you work on? Homepages

[tmcconechy]

On further review and comments from teans i think that we might consider make all modals and messages nest again and not close on each other.

Use Cases:

• modal then an error message
• modal then a lookup with a modal (hides the original modal and might be disconcerting) (see video)

[jamie-norman]

I think I agree with this. The nesting experience can get messy, but it does show some hierarchy. The content sizing of the modals still seems like a janky experience, but aside from setting some parent modal size and fitting successive ones into it—which could be worse—I don't have a better solution to offer.

[EdwardCoyle]

I honestly question the practice of using nested modals at all.

I can't help but think that the use case demonstrated above would be better suited as an in-page form with its parts connected by application routing of some sort. The only Modal-style component that should really ever open here would be that "Select List" Lookup being opened by itself to choose an option from that grid. I can see behind the overlay is an empty grid with no content whatsoever -- seems like that should be replaced with the form that creates the new List Report. Even if it did have content present, does the action of creating something new for addition to that list really need the original list to be present?

The forms displayed in the animation contain actions that seem to need a lot of context. I'm speaking without a ton of context myself, but our Modal component isn't intended for such use cases: Its intention is to display (at most) a few quick options that briefly pull the user out of the main application workflow. Things like a couple input fields, checks, switches, and then the user is on their way.

The changes I made in #3717 to the Modal to gain control of stacking/lifecycle also included the hiding of other windows that are currently open mostly because the original implementation wasn't correct (multiple windows present with overlays that stack and eventually black-out the page behind it, as seen here). In other design systems, you generally don't see this behavior because it's error-prone and difficult to reason about. Our Modal technically supports the nesting case for legacy reasons, but if there's an opportunity to avoid its use in newer features, we should do so.

If it's a question of needing to display some sort of hierarchy, to go back to my earlier point about application routing, maybe display of hierarchy through a process could be done with something like an in-page set of breadcrumbs or a wizard display?

I think about the only situation where I find it reasonable would be the one @SofiK asked to be solved here, where a simple "OK/Cancel"-type message could appear over top of an open Modal. Even that could be simplified with some combination of form validation, disabling of the Modal control buttons, and veto/acceptance of the Modal window being closed.

Ultimately, we can add the setting and re-establish the "stacking" hierarchy visually, but I personally think it's not the best solution to this problem, and it prolongs a poor UX practice.

[tmcconechy]

I was thinking that although nested modals suck/bad practice for some reason they still get used unfortunately.

I think there is cases for both maybe:

• modal -> lookup -> error
• modal -> lookup
• modal -> error

Dont all seem to bad. And maybe should be staying open to keep context but..

• modal with contacts -> open the supplier quick entry modal slide in is like different context so seems better to me if it closes like it does now.

So overall i think the setting will work and we can default to not "showing" that there is compex nesting going on. (Or maybe stacked by default for modal -> error and unstacked for otherwise)

[pwpatton]

This is also breaking landmark tests since there were multiple models and our test picked out the nth modal from a selector that returns a list of modals.

[lipetzan]

This not only breaks Landmark QA tests but also breaks any app or CQA QA team, internal or customer, that has automated tests written using modals, using TaaS (Krypton) or any 3rd party.

What is the decision here? Revert or continue on?

[tmcconechy]

My Vote: Revert - I.E. make it a setting and turn it ON by default

[EdwardCoyle]

@pwpatton one part of that modal change involved placing all "open" modal instances within a root container called .modal-page-container... could be why the tests are failing.

I'd rather us not enable the setting by default, per my comment about prolonging the use of the nested pattern, but sounds like we have to in order to get tests passing.

[tmcconechy]

Seems like the idea is sound but its not totally how every expected it to work. So i think due to the issues and complaints we probably need to have it "mostly like it was" in terms of the nesting and stack order.

[jbrcna]

QA Passed
test across all browsers and devices
v4.31.0-dev
https://master-enterprise.demo.design.infor.com/components/modal/test-nested

https://master-enterprise.demo.design.infor.com/components/modal/test-nested-no-underneath