Why does hide popover not have a cancelable event?

[annevk]

It seems a bit weird that only one beforetoggle event is cancelable. So you can only prevent a popover from being shown, not from being hidden.

cc @mfreed7 @josepharhar @nt1m

[josepharhar]

I'm not sure what the reason for this was, but I can confirm that chrome's implementation only has cancelable on showPopover not hidePopover.

Maybe it would have been a lot of extra complexity to handle some popovers not closing when other code calls HideAllPopoversUntil? Mason probably knows

[nt1m]

I thought a bit about this myself, I think potentially the complexity was for hiding popovers when the popover state changed to none, where you don't want to allow cancelling the event.

[mfreed7]

So we discussed this several times in OpenUI (here and here, primarily) and the main reason is that it's a huge footgun to cancel the hide event. Much of the logic of popover, as you know, is around handling the interactions between nested and non-nested popovers, and correctly handling light dismiss behaviors. Much of that unravels if one of the popovers cancels it's hide event. When that happens, it's kind of viral, and you end up having to re-implement all of the one-at-a-time and light dismiss behaviors in JS, likely incorrectly. Also, nobody came forward with a concrete use case that needed it.

Since the show transition is much easier to cancel without side effects, we made that one cancelable. Even there, there weren't use cases. So I'd be supportive of making show non-cancelable also, if that makes people more comfortable with the symmetry of the events. But I'd be against making hide cancelable.

[annevk]

Okay, I guess we'll just leave this as-is then.

[samgalam]

A use case I ran into is a datepicker (in a popover) that can also be changed via an input (not in the popover). I want all of the behavior of popover="auto" (esc to close, click outside to close, autoclosing other popovers) except when clicking on the input that controls the popover, in which case I don't want to close the popover. I guess I need to set popover="manual" and handle all of the light-dismiss behavior myself.

[mfreed7]

A use case I ran into is a datepicker (in a popover) that can also be changed via an input (not in the popover). I want all of the behavior of popover="auto" (esc to close, click outside to close, autoclosing other popovers) except when clicking on the input that controls the popover, in which case I don't want to close the popover. I guess I need to set popover="manual" and handle all of the light-dismiss behavior myself.

Yeah, with that use case I think you'll need to use popover=manual. There's also #9111 which might be useable to connect the input to the popover (for a popover=auto) which might keep it open. That all depends on what the resolution to #9111 turns out to be.

[jlukic]

Ran into this when showing a popover on pointerdown which is helpful to make offscreen menus feel more responsive on mobile.

The initial pointerup from the same gesture will cause it to hide, and since beforetoggle is not cancelable you cant really tell it to ignore the first click.

Seems like allowing beforetoggle to cancel would at least give the developers the discretion to handle coding custom logic like that described in the date picker example, or this one, even though they might in more complex examples risk, as you said, "shooting themselves in the foot".