[Modals] you can, in fact, prevent the Esc key from closing <dialog>

[domenic]

https://github.com/slightlyoff/history_api/blob/master/history_and_modals.md says

Additionally, note that the inability to prevent closing of <dialog>s via Esc makes them hard to use for some web developers, and requires them to roll their own custom dialog modals.

However, this is not true: you can intercept the keydown event and cancel it. https://jsbin.com/lifahuqopa/edit?html,output

There's even a specifically-designed event, that fires on the dialog itself, named cancel, for this purpose: https://jsbin.com/yadizivato/edit?html,output

I'm unsure how much this impacts of the rest of the explainer. Certainly it impacts the proposal for dialog integration. Hmm. But what about custom modals?

Credit to https://mobile.twitter.com/samthor/status/1339712302535208961

[dvoytenko]

Can "cancel" be default-prevented?

[domenic]

Yep, check out the example.

[dvoytenko]

Right. So the only issue is then preventing this to become a highjacking tool for the back button. E.g. we can make cancelevent.preventDefault() to be browser-mediated. I.e. the browser would show "unsaved data" prompt so that the back button cannot be indefinitely blocked.

[domenic]

Right, I agree with that issue. In particular, if we just said that the Android back button should close dialogs the same way that Esc does on desktop, including the cancel event being cancelable (default-preventable), then we'd run into the back-button-trapping problem. So we do need to do something more. I'll try to spend some time figuring out what that would look like...

---

I'll also note that, just at a surface level, the existence of the cancel event might impact the naming of this proposal. E.g. maybe beforeclose should become cancel, for symmetry with <dialog>? And maybe this whole concept should be renamed "modal cancel signals" and the API ModalCancelWatcher?

I think beforeclose + close is much clearer, personally, but <dialog> has gone with cancel + close, and we probably shouldn't diverge unnecessarily.

[dvoytenko]

I think cancel is already meant to be close to beforeclose. So if we can make it work with the behavior that we like, I think, we should try. E.g. we could go ahead and elect to show browser prompt when cancel is default-prevented when the back button support is available. We could add some indicator to the event that this is a browser-mediated event so that users can avoid writing their own "data not saved" dialogs? Or, e.g. we could only instrument that mode when dialog.showModal({backbutton: true}) is passed to preserve a cleaner backward comaptibility.