WICG / close-watcher

A web API proposal for watching for close requests (e.g. Esc, Android back button, ...)
https://html.spec.whatwg.org/multipage/interaction.html#close-requests-and-close-watchers
71 stars 5 forks source link

Potential issue with late-arriving initial popover #20

Open jakearchibald opened 2 years ago

jakearchibald commented 2 years ago

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:

  1. User navigates to site.
  2. Time passes, because the cookie banner loads slowly.
  3. Cookie banner appears.
  4. User presses esc and the cookie banner closes.

Great, but…

  1. User navigates to site.
  2. Time passes, because the cookie banner loads slowly.
  3. User opens a sidebar, which also uses CloseWatcher.
  4. Cookie banner appears over the top.
  5. User presses 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?

jakearchibald commented 2 years ago

This behaviour changes the cancel behaviour of this in a way that might not be desirable:

  1. User clicks thing to open popover.
  2. User tries to close popover with Android back gesture.
  3. Page prevents default on cancel, and creates confirmation <modal>.
  4. User again uses Android back gesture.

The current spec'd behaviour is:

  1. User clicks thing to open popover.
  2. User tries to close popover with Android back gesture.
  3. Page prevents default on cancel, and creates confirmation <modal>. This cannot create a close watcher, since there was no user activation.
  4. User again uses Android back gesture. This signals close of the first popover, but not the confirmation modal.

My proposal would change it to:

  1. User clicks thing to open popover.
  2. User tries to close popover with Android back gesture.
  3. Page prevents default on cancel, and creates confirmation <modal>. This successfully creates a close watcher, as there are no other 'without activation' watchers active.
  4. User again uses Android back gesture. This signals close of the dialog.

A further Android back gesture will signal close of the popover.

domenic commented 2 years ago

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...