Allow "notificationclick" to focus/open windows

[jakearchibald]

Following on from w3c/ServiceWorker#602 (comment), notificationclick handlers should be able to focus/open windows via the clients API in the ServiceWorker.

A typical pattern would be:

self.addEventListener('notificationclick', function(event) {
  if (event.notification.tag == 'chat') {
    client.matchAll().then(clients => {
      return clients.find(c => new URL(c.url).pathname.indexOf('/chat/') === 0);
    }).then(client => {
      if (client) {
        client.focus();
      }
      else {
        clients.openWindow('/chat/');
      }
    });
  }
});

Since .matchAll is async, does the spec need to take this into account to allow focusing/opening of windows?

https://html.spec.whatwg.org/#allowed-to-show-a-popup mentions a user-agent defined timeframe of ~4 seconds.

[mounirlamouri]

Chrome is going to implement a timeframe of 10 seconds.

[annevk]

Shouldn't the HTML specification be modified for this? "Allowed to show a popup" is based on stack inspection.

[jakearchibald]

Do you mean that tapping on a notification should count as "Allowed to show a popup"? That means tapping a notification would be able to show a file dialog, make an element full screen etc. Is that desirable?

[annevk]

Probably? I'm not sure. Someone would have to ask UX.

[adrifelt]

I don't think that tapping a notification should count towards showing a file dialog or making an element full screen.

[annevk]

Yeah true, although none of that would be possible anyway from a service worker.

So... @jakearchibald, you want an equivalent definition of "allowed to show a popup" it sounds like, but wouldn't it be better if that was part of the service worker specification?

[jakearchibald]

Just to clarify, are you suggesting:

• Create a definition similar to "allowed to show a popup" that only allows window focusing/opening
• Add notificationclick and click to that definition
• Remove the "User agents are encouraged to make window.focus()" bit from the notification spec, as it's no longer needed

Given that https://html.spec.whatwg.org/#allowed-to-show-a-popup lists click as one of the allowed event types, does this mean that clicking notification created by a page can still do all the fullscreen & file dialog stuff that we don't want it to do?

[annevk]

I don't understand click. In the context of a service worker only notificationclick seems relevant. What am I missing?

[mounirlamouri]

For the sack of being abstract enough, I would call this user interaction and say that notificationclick event represents a user interaction. There might be other events representing a user interaction.

[jakearchibald]

@annevk

I don't understand click. In the context of a service worker only notificationclick seems relevant.

I don't think this is a serviceworker-only issue. The way I see it:

• You should be able to focus/open a window after tapping a notification
• You should not be able to make an element fullscreen, or open a file dialog, or any other actions that currently use "allowed to show a popup", after tapping a notification

Tapping a notification is not serviceworker specific. You can do this from a page by creating a notification and listening for its click event (https://notifications.spec.whatwg.org/#activating-a-notification 4.7.2.1).

[jakearchibald]

Thinking about this more. notificationclick should be part of "allowed to show a popup".

"allowed to show a popup" should only apply to the current global, so you can't get a notificationclick, then postMessage to a window, and then show file select dialog from that window.

If clicking a notification shouldn't be able to make elements fullscreen, open a file dialog etc, then we need something other than "allowed to show a popup".