A modal should not open another modal
Aliases: modal-in-modal · stacked dialogs · nested dialog
What it is
Opening a second dialog from a dialog that already blocked the main flow is a nested modal. The outer question is still unanswered; the inner one now locks the outer. The inner must be solved to return to this layer, and this layer must be solved to return to the main task. Two “must respond” claims sit on top of each other, and it becomes unclear which one is the real precondition. This forbids dialog-in-dialog. It is not a cap on overlay count, and not about how focus is closed.
Why it happens
A modal’s contract is: you face this one question now, and answering it returns you to the main surface. A second modal rewrites the contract: the question becomes a question about the question, and the return stack grows from “main ← dialog” to “main ← outer ← inner.” Working memory has to hold two open decisions, both claiming urgency. If the inner is validation of the outer (“name taken, rename?”), it belongs as inline error inside the outer, not as another lock. If the inner is an unrelated event (session expired, a system notice), it is interrupting an interruption, and urgency cannot be ordered. Stacked scrims also make the outer look like main content, so closing the inner feels like a return to the app when the user is still trapped in the outer. Nesting breaks the very rule modality depends on: one precondition at a time.
Studying it
Build a task that must be finished inside a dialog. One version puts the secondary decision inline; the other opens a second modal. Record time, closes of the wrong layer, and times the user thought they were back on the main surface. Independent variables: whether the inner is related validation or an unrelated interrupt. Dependent variables: layer errors (closing the wrong one), abandon rate. Unrelated inner pops should show the highest abandon. In replay, watch which layer’s scrim the close lands on.
Where it stops holding
OS permission sheets and crash alerts may appear above an app modal; the app cannot forbid that, but it should not add its own stack. Wizard steps should change page or panel, not open one modal per step. A non-modal picker (a date popover) inside a modal is still a layer; if it does not claim modality, does not lock the outer dialog, and a tap outside closes only the picker, it is not nested modality. Closing the outer first and then opening a new modal is a change of question, not nesting — provided the outer’s state is explicitly saved or discarded.
Applying it
- Keep validation, second confirms, and copy inside the dialog as inline or expanded content; do not open another dialog.
- When a global event such as session expiry arrives, close or suspend the current modal and then handle the global event; do not cover it.
- If another full conversation is required, finish the current modal and account for its state, then open the next.
- How to check: walk a submit that includes validation and count open dialogs. More than one at a time is still nesting.
Related
- Within the group: E4.10.1 A modal blocks the main flow and belongs only on matters that must be answered · E4.10.2 A modal must trap focus and restore it on close · E4.10.4 A modal must offer a keyboard-reachable way to close
- Adjacent: E4.16 Overlay stacking and escape · E4.12 Popovers
- Search terms:
nested modal·dialog stacking·modal in modal