Open jakearchibald opened 2 years ago
This behaviour changes the cancel behaviour of this in a way that might not be desirable:
cancel
, and creates confirmation <modal>
.The current spec'd behaviour is:
cancel
, and creates confirmation <modal>
. This cannot create a close watcher, since there was no user activation.My proposal would change it to:
cancel
, and creates confirmation <modal>
. This successfully creates a close watcher, as there are no other 'without activation' watchers active.A further Android back gesture will signal close of the popover.
I'm unsure how you get "the sidebar closes" in your initial scenario. Is it because the web developer created the cookie-banner CloseWatcher
when they initially loaded the page (before the sidebar was shown and its CloseWatcher
was created), instead of when they were actually ready to show the cookie banner (which is after the sidebar was shown and its CloseWatcher
was created)?
A close signal (Esc or whatever) will always close the "top of the stack", so yeah, be sure you create your close watchers in the same order the user sees them...
I'm thinking specifically of cookie banners, as these seems to load particularly late.
Let's say a site contains a cookie banner that uses
CloseWatcher
:esc
and the cookie banner closes.Great, but…
CloseWatcher
.esc
expecting the cookie banner to disappear, but the sidebar closes.Right now the spec only allows a
CloseWatcher
to be created without user activation if the close watcher stack is empty (roughly). Maybe it should change so that the stack may only contain one close watcher that was created without user activation?