Queued notifications should no longer be displayed after the service worker is unregistered
Categories
(Core :: DOM: Service Workers, enhancement, P3)
Tracking
()
People
(Reporter: atrif, Unassigned)
References
(Blocks 1 open bug, )
Details
Attachments
(1 file)
6.02 MB,
image/gif
|
Details |
Affected versions
- 74.0a1 (20200129213721)
Affected platforms
- Windows 10x64
Steps to reproduce
- Open Firefox and go to https://serviceworke.rs/push-payload_demo.html.
- Click to Allow notification for the web page.
- Go to about:debugging#/runtime/this-firefox and click on the “Push” button several times.
- Click on the “Unregister” button for the service worker registered in Step 1.
Enhancement suggestion
- The queued notifications are stopped.
Actual result
- Queued notifications are still delivered.
Notes
- It seems that happens only on windows, at least on the mentioned website. On macOS 10.15 the notifications are stacked after pressing the "Push" button several times, and Ubuntu delivers the notification instantly for each time the "Push" button is pressed. I can't seem to see other notifications after following the above STR on Ubuntu 18.04 or macOS 10.15.
- dom.serviceWorkers.parent_intercept is set to false on Firefox 73 and 72.
Updated•4 years ago
|
Comment 1•4 years ago
|
||
Is there anything in a spec somewhere that speaks to what should happen with queued notifications?
Updated•4 years ago
|
Comment 2•4 years ago
|
||
(In reply to Andrew Overholt [:overholt] (returning March 6th) from comment #1)
Is there anything in a spec somewhere that speaks to what should happen with queued notifications?
I believe the spec says to drop any events that haven't been handled yet or aren't in the process of being handled: "Try Clear Registration" in https://w3c.github.io/ServiceWorker/#unregister-algorithm. On the demo site though, the notifications are queued on the server, so it wouldn't know anything about the state of the client and is free to try to send the push notifications.
atrif, to confirm, the notifications still appear after the ServiceWorker entry is removed from about:debugging#/runtime/this-firefox (one "Unregister" is pressed)?
Comment 3•4 years ago
|
||
I think it's probably worth noting that the queue-ing sounds like it's happening in the https://notifications.spec.whatwg.org/ API rather than the Push API, and I think our implementation doesn't really pay attention to the registration being removed. The call path would be:
- registration.showNotification
- Notification::ShowPersistentNotification this takes a
ServiceWorkerRegistrationDescriptor
but just uses it to run very minimal checks at the time the call is made. - Notification::CreateAndShow will end up handing things off to the nsIAlertService which is platform specific and presumably our Windows nsIAlertService does the toaster thing with queueing whereas linux does not.
Reporter | ||
Comment 4•4 years ago
|
||
(In reply to Perry Jiang [:perry] from comment #2)
(In reply to Andrew Overholt [:overholt] (returning March 6th) from comment #1)
Is there anything in a spec somewhere that speaks to what should happen with queued notifications?
I believe the spec says to drop any events that haven't been handled yet or aren't in the process of being handled: "Try Clear Registration" in https://w3c.github.io/ServiceWorker/#unregister-algorithm. On the demo site though, the notifications are queued on the server, so it wouldn't know anything about the state of the client and is free to try to send the push notifications.
atrif, to confirm, the notifications still appear after the ServiceWorker entry is removed from about:debugging#/runtime/this-firefox (one "Unregister" is pressed)?
Yes, the notifications are still shown after the unregister button is pressed. The only thing different is that on Firefox 74.0 the notifications are stacked now, as seen in the recording. But filling the area with notifications and Unregister the service worker will keep the queued notifications appearing.
When I first noticed this, Nightly had notifications displayed one after another, not stacked, but that has been changed, I think by bug 1614274.
Updated•1 year ago
|
Description
•