What should "nested" dialog light dismiss look like?

[mfreed7]

I have a spec PR open to add dialog "light dismiss" capabilities, via a new closedby attribute, here: whatwg/html#9373. One question came up (see discussion starting roughly here) about what the behavior should be for "nested" dialogs. I keep putting quotes around "nested" because dialogs don't have any current notion of being "nested", in the same way that popovers explicitly do (see the big Note here: https://html.spec.whatwg.org/#topmost-popover-ancestor). So any behavior we add here is essentially inventing some concept of nested dialogs.

So the question is, what are typical expectations for users or developers when multiple modal dialogs are open, and the user clicks outside one of them. I'd like to side-step the question of modeless dialogs, at least for now, since I consider modals the more pressing, and common, use case.

Here's a demo to work with (borrowed and tweaked from @domenic):

Some things to note:

• while the dialogs definitely look "nested", they are in fact siblings in the DOM tree. Their order in the DOM does not matter for this visual presentation, only the order of the showModal calls.
• both dialogs are modal, so both have a ::backdrop covering the area outside the dialog.
• due to the above, a click outside inner is actually a click on inner's ::backdrop. It is impossible to click on outer or its ::backdrop.

There are three positions that a user might try to click (labeled in red in the demo above):

1. Within inner's border box.
2. Within the visible portion of outer's border box.
3. Outside both dialogs' border boxes.

Note, again, that #2 and #3 are both actually clicks on the backdrop of inner.

In terms of potential outcomes, for each click position:

1. Clicking on inner should always leave inner visible. It could either close outer or leave it open. It seems like it makes the most sense to leave outer open, at least to a user for this use case.
2. This is a click outside inner, so inner should clearly close. And because it's an attempted click on outer, it seems like outer should stay open.
3. Clearly, inner should close, since it is topmost. The question is whether the user expects this click to just close inner and leave outer open (i.e. just pop one dialog off the stack), or whether both should close. My assumption is that in all design systems today that implement "light dismiss dialogs", outer stays open, just due to implementation. But I'd love confirmation.

The point of this issue is a) to make sure I haven't missed something, and b) to check expectations for behavior. I'd love to discuss, so Agenda+.

[keithamus]

1. Clicking on inner should always leave inner visible. It could either close outer or leave it open. It seems like it makes the most sense to leave outer open, at least to a user for this use case.

Yes, it's important that clicking on inner should not close any lower dialogs. It should leave outer open.

2. This is a click outside inner, so inner should clearly close. And because it's an attempted click on outer, it seems like outer should stay open.

Right. Only one dialog should close at a time. Closing many may be an unpredictable behaviour, and would sow distrust for the user as to what they can anticipate.

3. Clearly, inner should close, since it is topmost. The question is whether the user expects this click to just close inner and leave outer open (i.e. just pop one dialog off the stack), or whether both should close. My assumption is that in all design systems today that implement "light dismiss dialogs", outer stays open, just due to implementation. But I'd love confirmation.

We have some nested dialogs where outer stays open, and it is a carefully considered design choice. It is important to us that the implied behaviour is "just pop one off the stack" because it allows for a very predictable consistency, whether or not the developer made them nested or not, and regardless of the "type" (hint, popover, dialog, etc).

In the above image, there is actually a more complex case: the Discard changes? dialog can be light dismissed, which acts like the Keep editing button. Attempting to light dismiss dialog "Create new issue" will invoke the "Discard changes?" dialog, in order to intercept the user before they are able to dismiss this dialog and potentially reset their work. For us it is important that clicking the backdrop always does something; either light dismiss the current top dialog, or present a new dialog (or some kind of visual confirmation) showing that the light dismiss has been prevented.

[mfreed7]

We have some nested dialogs where outer stays open, and it is a carefully considered design choice. It is important to us that the implied behaviour is "just pop one off the stack" because it allows for a very predictable consistency, whether or not the developer made them nested or not, and regardless of the "type" (hint, popover, dialog, etc).

This is very helpful - thanks.

In the above image, there is actually a more complex case: the Discard changes? dialog can be light dismissed, which acts like the Keep editing button. Attempting to light dismiss dialog "Create new issue" will invoke the "Discard changes?" dialog, in order to intercept the user before they are able to dismiss this dialog and potentially reset their work. For us it is important that clicking the backdrop always does something; either light dismiss the current top dialog, or present a new dialog (or some kind of visual confirmation) showing that the light dismiss has been prevented.

Thanks also for this use case. I believe this should be easy to implement, within the currently proposed behavior (whatwg/html#9373), by adding a listener for the outer dialog's cancel event, and preventDefaulting it as needed. Does that seem correct?

[keithamus]

Thanks also for this use case. I believe this should be easy to implement, within the currently proposed behavior (whatwg/html#9373), by adding a listener for the outer dialog's cancel event, and preventDefaulting it as needed. Does that seem correct?

Yes absolutely. No concerns on that particular behaviour.

[mfreed7]

So I updated Chrome's behavior to match what's roughly being proposed in the conversation above, namely that clicking outside a "stack" of dialogs only "pops" the first one off the stack. So for N dialogs, you'll need N clicks outside to close them all. The behavior for popovers meshes fairly well with this also, or at least that was my impression. So I've roughly come around to thinking this is likely the better/correct behavior.

But if folks want to try it out live, grab Chrome Canary (minimum 133.0.6878.0) and give it a try! Please remember to add <dialog closedby=any> to your dialog, or you'll get the existing behavior - no light dismiss. You can use the demo from the OP here, if you want.

[sorvell]

just pop one dialog off the stack

I definitely think this is the correct behavior.

Sorry this is probably a bit obtuse, but in general a modal dialog is intended to / must be responded to in some way. I think it's common in these cases that a "parent" dialog spawns the "nested" one, and this often obscures the "parent." Responding to the "nested" dialog does not respond to the "parent," and as a user I expect to be able to get back to the "parent" and respond to it directly. Otherwise, I'm flummoxed with "where did that other dialog go?"

[lukewarlow]

The update definitely feels like the better behaviour.

[lukewarlow]

https://jsbin.com/pesomokilo/edit?html,output - The behaviour when you press escape here closing the back modal feels perhaps wrong to me (I could be convinced either way though)? Is this behaving as specced or is this expected to change?

[domenic]

The behaviour when you press escape here closing the back modal feels perhaps wrong to me (I could be convinced either way though)? Is this behaving as specced or is this expected to change?

This is due to the current spec's CloseWatcher anti-abuse grouping. A more realistic example that has user activation does not exhibit the problem: https://jsbin.com/yefajififu/edit?html,output

[keithamus]

@domenic do you think the internals of showModal() could circumvent the anti-abuse grouping? If a web author has called showModal() on a lot of dialogs then closing them in an order different to what they're shown does seem odd. It is of course an edge case but it might be tractable to solve for, no?

[domenic]

I'm not clear on what you're envisioning. Circumventing anti-abuse grouping sounds like allowing abuse, which is bad?

[keithamus]

The anti-abuse mechanisms are multi-variant so it's not a linear path from anti-abuse to abuse though? I am suggesting that showModal() always creates a new group so that the stack of close watcher groups is >= the number of open modals; N. I believe the other anti-abuse mechanisms will still function such that pressing escape twice will always result in a forced close which means at most a user will have to press escape N+1 times AIUI.

[domenic]

That trivially allows abuse: you then call showModal() N times and you now have trapped the user (they require N back presses to exit the site).

The point of the anti-abuse mechanisms is to cap the number of back presses at (number of user activations) + 1, i.e. put the user in control. Capping it at (number of showModal() calls) + 1 puts the developer in control, but the developer is the potential abuser.

https://github.com/WICG/close-watcher?tab=readme-ov-file#abuse-analysis may be worth reviewing.

[lukewarlow]

Fwiw I'm fine with the odd behaviour given it only applies in these anti-abuse cases, and with the mix of closedby values. It feels edge case enough that it'll almost never come up (other than for us spec and implementor people who think about these cases)

[mfreed7]

Pending @keithamus's agreement, it sounds like perhaps we've somewhat arrived at consensus? For me at least, with the new behavior, both this (@lukewarlow's example) and this (@domenic's example) feel "ok" to me. Both are somewhat odd situations, where the "outer" dialog is closedby=any but the inner is closedby=none. I would think that in a real situation, if your outer dialog can open non-light-dismissible dialogs, then it shouldn't be light dismissible itself. Or, if you need that, use @domenic's code path, where the inner one is user activated.

Assuming there are no other objections, I'm inclined to go back to the spec PR and say we now have the right behavior. So... any objections to that?

[domenic]

(The above post is a bit confused. I will hide it. This is a second attempt.)

Although the above comments are talking about the behavior for close requests (Esc key / Android back button), there is a related issue which is whether the anti-abuse mechanisms should apply to light dismiss and requestClose().

Recall that the anti-abuse protections come in two parts:

1. Inside request to close, we only allow the cancel event to be preventDefault()ed under certain circumstances, and we consume history-action user activation if preventDefault() is called.
2. Inside process close watchers, we can close multiple close watchers at the same time if they are grouped. (Grouping happens when you create multiple close watchers without user activation.)

(2) is only relevant for close requests, so that's fine. Most of the above discussions were talking about (2).

But (1) is being applied to CloseWatcher's requestClose(), and (per the proposal in whatwg/html#10737) to <dialog> light dismiss and requestClose(). It does not have to be, since there is no abuse potential in those scenarios.

Should we consider bypassing (1) for those cases? To spec this I would probably add an optional requireHistoryActionActivation boolean to "request to close" and set it to true for close requests, and false for light dismiss and requestClose(). This might require updating some test expectations for CloseWatcher.

[mfreed7]

But (1) is being applied to CloseWatcher's requestClose(), and (per the proposal in whatwg/html#10737) to <dialog> light dismiss and requestClose(). It does not have to be, since there is no abuse potential in those scenarios.

Should we consider bypassing (1) for those cases? To spec this I would probably add an optional requireHistoryActionActivation boolean to "request to close" and set it to true for close requests, and false for light dismiss and requestClose(). This might require updating some test expectations for CloseWatcher.

Ohh this is a good point. I agree that there doesn't seem to be any abuse potential in either light dismiss (where the user isn't hitting a "close" button which might be trying to navigate back) or in the developer calling dialog.requestClose() (the user isn't doing anything directly). So I'm in favor of this change.

Any objections from developers here? I don't see why there would be objections, but just checking. Otherwise, I'll take a look at adding some way around the abuse protections in the dialog spec PR. @domenic, if you have specific suggestions for a good way to go about that, I'm all ears. My first thought is to just add a boolean parameter to request to close that will force canPreventClose to true.

[mfreed7]

Otherwise, I'll take a look at adding some way around the abuse protections in the dialog spec PR. @domenic, if you have specific suggestions for a good way to go about that, I'm all ears. My first thought is to just add a boolean parameter to request to close that will force canPreventClose to true.

whatwg/html@6aa7386

[mfreed7]

Should we consider bypassing (1) for those cases? To spec this I would probably add an optional requireHistoryActionActivation boolean to "request to close" and set it to true for close requests, and false for light dismiss and requestClose(). This might require updating some test expectations for CloseWatcher.

@domenic somehow I totally missed this paragraph of your comment. Thanks for the specific suggestion - I just flipped the name and logic of my last commit to match. Note that I think we should handle the closeWatcher.requestClose() case separately because it might have compat issues. I doubt it, but I'd like to separate it from the dialog stuff, which doesn't have that problem.

[domenic]

Note that I think we should handle the closeWatcher.requestClose() case separately because it might have compat issues. I doubt it, but I'd like to separate it from the dialog stuff, which doesn't have that problem.

I'm a little sad about introducing dialogEl.requestClose() which has different behavior than closeWatcher.requestClose(), so my instinct would be to bundle that change in. Especially given how unlikely the compat issues would be. (It's relatively hard to depend on an event being non-cancelable, I think...)

But, I trust you to fast-follow with such a change, if you would prefer to split them.

[mfreed7]

I'm a little sad about introducing dialogEl.requestClose() which has different behavior than closeWatcher.requestClose(), so my instinct would be to bundle that change in. Especially given how unlikely the compat issues would be. (It's relatively hard to depend on an event being non-cancelable, I think...)

Yeah that's fair, compat might not be that bad. Ok. I'll try to put them together and ship them both at the same time. 😄

[css-meeting-bot]

The Open UI Community Group just discussed What should "nested" dialog light dismiss look like?, and agreed to the following:

• RESOLVED: the latest spec PR behavior seems ok

The full IRC log of that discussion

<hdv> masonf: this might be resolved… but want to make sure we're not missing anything
<hdv> masonf: when I worked on light dismiss for dialogs, there came up the question what about multiple dialogs that are nested?
<hdv> masonf: if you stack a bunch of dialogs and click outside of them, the top most one gets light dismissed, ther rest doesn't. So if you have three, you'd need to click 3 times for them all to go away
<scott> q+
<hdv> masonf: for dialogs it seemed to make most sense to have that behaviour
<hdv> masonf: does anyone feel this is funny in some way?
<masonf> ack scott
<hdv> scott: what you said makes sense to me… would the same thing happen with the Esc key ?
<lwarlow> q+
<hdv> masonf: yes
<hdv> masonf: yes*
<hdv> masonf: *there are some corner cases
<hdv> masonf: the new closeby attr allows you to chose between any close request, or none
<hdv> masonf: there are some funny cases where closeby=any on the first dialog and then closeby=none on the third one on top, it feels funny. But then mixing and matching different closeby values in a stack of dialogs is funny anyway
<hdv> scott: just wanted to make sure it works the same with clicking outside and escape
<masonf> q?
<masonf> ack warlow
<masonf> ack lwarlow
<hdv> masonf: this is why there are 3 closeby attr values… we wanted to explicitly make sure that @@@
<hdv> lwarlow: regarding Esc… if people back navigate on Android… from what I've seen it's not a common thing to come up
<hdv> lwarlow: the only weird thing would be a weird mix of closeby values and dialogs vs popovers
<hdv> lwarlow: if we find a weird edge case for thsi that we find after we ship it, it'd probably not be hard for us to fix it
<hdv> masonf: yes seems to me too, as long as not many people have used it yet and there are no compat issues
<masonf> q?
<masonf> Proposed resolution: the latest spec PR behavior seems ok
<lwarlow> +1
<hdv> lwarlow: it's odd it doesn't use the attribute change stacks
<hdv> lwarlow: feels more complicated not to do that
<hdv> lwarlow: but I get how we did it seems fair
<hdv> lwarlow: with the open attribute it gets that anyway
<hdv> masonf: the case where you remove the open attr and then don't call close; that is fixed with the PR this week, but if you'd do that it'd be funny anyway
<hdv> masonf: so you're still ok with the behaviour?
<hdv> lwarlow: yeah
<masonf> RESOLVED: the latest spec PR behavior seems ok

[mfreed7]

I'm going to close this issue, since we discussed and resolved on the latest spec behavior.