Open saschanaz opened 5 months ago
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.
Also I should note that https://github.com/w3c/ServiceWorker/issues/1512 would potentially decouple scopes from registrations.
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
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.