Should persistent notifications be associated with service worker registration or the scope?

[saschanaz]

What is the issue with the Notifications API Standard?

I just found that both Firefox and Safari associate the notifications with the scope instead for getNotifications(), while the spec says:

https://notifications.spec.whatwg.org/#dom-serviceworkerregistration-getnotifications

Let notifications be a list of all notifications in the list of notifications whose origin is same origin with origin, whose service worker registration is this, and whose tag, if tag is not the empty string, is tag.

Blink does the association as the spec says, and closes all the notifications when the SW is unregistered. I'm adding a tentative test in https://phabricator.services.mozilla.com/D202612 for Gecko/WebKit behavior as that's the majority, but worth a discussion.

[asutherland]

I think registration is correct. Arguably the current use of registration allows the spec to hand-wave the lack of steps like the push API's deactivation text.

Given the removal of registration resurrection from the SW spec, and because the SW job queue mechanism does operate in terms of scopes, specifying persistent notification in terms of scope I think ends up much more constraining for implementations because notifications would inherently need to run a set of steps as part of the ServiceWorker unregister job. (Although I suppose this is already the case for push citing registration clearing.)

That said, I think the notifications spec could benefit from additional clarity like the push deactivation text.

[asutherland]

Also I should note that w3c/ServiceWorker#1512 would potentially decouple scopes from registrations.