[Popup] Light dismiss "escape key" should probably include all close signals

[domenic]

The popup explainer says

An opened popup will have “light dismiss” behavior, meaning that it will be automatically hidden when:

• The user hits the escape key,

@dvoytenko and I have been working on https://github.com/slightlyoff/history_api/blob/master/history_and_modals.md, which is quite related. We believe that this escape key mention should probably be expanded to cover all "close signals", including:

• Esc on desktop
• Android back button
• Accessibility technology gestures (e.g. iOS two-finger scrub)
• Maybe even game console buttons

@natechapin is working on a Chromium implementation of this concept, that so far intercepts both the desktop Esc key and the Android back button.

Our plan is to have all parts of the platform which use these close signals, e.g. the fullscreen API or the <dialog> element, use a core unified definition. Hopefully <popup> will too.

(Separately, some of the explainer linked above also talks about a ModalCloseWatcher class to allow direct developer handling of close signals. But, that would just be another consumer of this core "close signal" concept. The overlap with <popup> is about the hopefully-shared concept.)

[mfreed7]

I was just going to raise another issue about the Escape key, but I think it might make sense to discuss it as part of this issue. During implementation, the question has come up about whether the Escape key light dismiss behavior (or really, any of the light dismiss behavior such as clicking outside) should be author-cancellable. I.e. user hits Escape, but author has added 'keydown' event handler on document.body, and does preventDefault(). Should the currently-top popup be hidden?

If you think this should be a separate issue, I'm happy to open one.

[domenic]

Oh, I think this is a great discussion to have here. It connects in interesting ways.

First, I think the platform needs to have both author-cancelable and non-cancelable close signals. Notably, exiting fullscreen cannot be author-cancelable. But, exiting a <dialog> is (and we have some strong feedback that it should continue to be).

Second, I think that the behavior should be uniform. So, you can prevent dialog closing by preventDefault()ing Esc on document. It also has an explicit cancel event which can be preventDefault()ed. (But, its close cannot be preventDefault()ed; that happens after the fact.) This means that, IMO, anything with cancelable close behavior should behave the same way, both in terms of keydown event listeners (on desktop) and also having a cancel event where applicable.

(Note: the modal close signals explainer was written before I realized this about dialog. Per slightlyoff/history_api#13, we're probably going to update the event name for ModalCloseWatcher in the way the above paragraph discusses, i.e. change beforeclose to cancel, to match <dialog>. Maybe we'll even rename it to ModalCancelWatcher.)

I don't have a strong opinion on which category <popup> should go in. @melanierichards mentioned in #455 that the current plan is for it to be in the uncancelable category. If so, then I think it should behave like fullscreen and keydown listeners shouldn't be able to stop it, and it shouldn't have a cancel event, etc.

Now, there's an interesting wrinkle for author-cancelable close signals regarding the Android back button, which is that canceling them can be used to trap the user by disabling the back button. Our modal close signals explainer has some mitigations for this, and for platform predictability, it applies those mitigations on all platforms.

P.S. it's kind of annoying to talk about these things because events are cancelable (preventDefault()able), but one of the major events we're talking about is named cancel 😆

[melanierichards]

Thanks @domenic! The original issue topic seems like a good one to port over to Open UI when we bring the proposal there for incubation. The group has been working on a full/shared definition of light dismiss (possibly that could be ported into the HTML spec at some point?). I imagine your feedback applies to light dismiss as generalizable behavior, as opposed to just applicable to popups.

Cancelable-or-not for popup also seems like a good topic to bring to group discussion. It would be good to better understand the use cases for cancellation and either a) determine if these can be addressed via other means or b) weigh the tradeoffs between developer ergonomics/consistency vs. the concerns of abuse.

[melanierichards]

Created issues #320 and #321 to track this conversation in Open UI!