Open Bug 1612300 Opened 4 years ago Updated 1 year ago

Queued notifications should no longer be displayed after the service worker is unregistered

Categories

(Core :: DOM: Service Workers, enhancement, P3)

74 Branch
Desktop
Windows
enhancement

Tracking

()

Tracking Status
firefox72 --- disabled
firefox73 --- disabled
firefox74 --- affected

People

(Reporter: atrif, Unassigned)

References

(Blocks 1 open bug, )

Details

Attachments

(1 file)

Affected versions

  • 74.0a1 (20200129213721)

Affected platforms

  • Windows 10x64

Steps to reproduce

  1. Open Firefox and go to https://serviceworke.rs/push-payload_demo.html.
  2. Click to Allow notification for the web page.
  3. Go to about:debugging#/runtime/this-firefox and click on the “Push” button several times.
  4. 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.

Is there anything in a spec somewhere that speaks to what should happen with queued notifications?

Flags: needinfo?(perry)

(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)?

Flags: needinfo?(perry) → needinfo?(alexandru.trif)

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:

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

Flags: needinfo?(alexandru.trif)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.