Add `requestClose()` function to HTMLDialogElement

[lukewarlow]

What problem are you trying to solve?

Dialog elements have an internal close watcher which can trigger cancel events to give web developers a chance to prevent the closure. Currently there's no way for developers to get access to this functionality via anything other than the internal close watcher.

Developers will often want to trigger this same behaviour if closed through other mechanisms such as custom light dismiss for dialogs or even cancel buttons themselves.

What solutions exist today?

The developer would have to implement the cancellation logic twice once for the cancel event handler and another time for their custom cancel behaviour.

How would you solve it?

Exposing a new requestClose() function on dialogs that that simplified would be firing the cancel event and then firing close event (and associated dialog closing steps) if cancel wasn't prevented.

Anything else?

[lukewarlow]

This has come up in a few conversations but primarily from a discussion about adding a 'cancel' (nameTBD) action to invokers for dialogs, and also the light dismiss for dialog discussions.

openui/open-ui#950 (reply in thread) - @domenic mentions that this is a useful functionality that we should probably expose.

[mfreed7]

As I'm speccing and implementing light dismiss behaviors for <dialog> over on #10737, @dbaron's code review made me realize a potential issue/question:

I had been thinking this new requestClose() method on dialog would work for both modal and non-modal dialogs. And the natural way to implement it would be for that method to just call the dialog's close watcher's "request to close" method. That nicely takes care of several kinds of issues, such as recursion checks ("is running cancel action") and the like.

However, non-modal dialogs don't get a close watcher. The "easy" thing is to say that requestClose() only works on modal dialogs. And I'm ok with that, but wanted to run it by especially @domenic who requested this feature. The alternative doesn't feel web compatible: add a close watcher to non-modal dialogs. I'm fairly positive (without supporting data) that will break the web.

Suggestions? Would we be ok with dialog.requestClose() throwing an exception if dialog isn't modal? That would nicely solve the problem, and feels like yet another reason for people to prefer either modal dialogs, or <dialog popover>'s, but not old-school modeless dialogs. Which I support. 😄

[lukewarlow]

Non-modal dialogs can get a close watcher if the closedby value isn't in the none state (though that state is the default). Perhaps requestClose() should no-op or throw when in this state, for both modal and non-modal dialogs.

[mfreed7]

Non-modal dialogs can get a close watcher if the closedby value isn't in the none state (though that state is the default). Perhaps requestClose() should no-op or throw when in this state, for both modal and non-modal dialogs.

Right. Sorry. I suppose I should have said that an exception gets thrown for a dialog whose closedby attribute is in the none state. (I was mostly thinking about existing dialogs that lack a closedby attribute, which will be in the none state.) Thanks!

[lukewarlow]

I guess the three options are:

• no-op
• throw
• fallthrough to directly calling 'close the dialog' algorithm?

My initial hunch is that throwing is best but I might be wrong.,

[lukewarlow]

Alternatively and this is just off the top of my head idea so apologies if I'm missing something obvious.

Is it possible that perhaps dialogs should always have an internal close watcher and its enabled Boolean is what gets toggled by this new attribute? And then we just only care about that Boolean when processing close watchers? But not when calling the algorithms such as 'request to close' directly? This way existing non-modal dialogs wouldn't close on escape press but you could still reuse the close watcher infra for this function?

[mfreed7]

Thanks for the thoughts. So I've spent today implementing the "throw" behavior, and adding it to the spec. After doing that, it feels pretty natural, and seems to have fewer footguns than either "no-op" or "fallthrough". Both of those seem like surprising (and semi-silent) behavior, vs. getting an exception that tells you exactly why things are weird.

But please take a look at the new spec PR text #10737 and also the updated set of tests right here, and let me know what you think.