Trigger a service worker soft update for failed pushes

NEW
Unassigned

Status

()

Core
DOM: Push Notifications
P3
normal
2 years ago
2 years ago

People

(Reporter: kitcambridge, Unassigned)

Tracking

(Depends on: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

https://w3c.github.io/push-api/ says:

> A user agent SHOULD invoke the Soft Update algorithm for the service worker registration in response to each failure so that errors in scripts can be corrected.

https://github.com/w3c/push-api/issues/115 suggests triggering a soft update for all `push` events, but Martin noted some complications with that.

Comment 2

2 years ago
So, if you dispatch a push event we already do handle the update here:

https://dxr.mozilla.org/mozilla-central/source/dom/workers/ServiceWorkerPrivate.cpp?q=ServiceWorkerPrivate.cpp&redirect_type=direct#463

That has a 24 hour time check, though.  I guess you don't want that here?

Calling MaybeScheduleUpdate() for failures would cause us to bypass that 24 hour check and shouldn't really cause any harm.  Since we use a timer mechanism we should end up debouncing the updates pretty well already.
The 24-hour check is actually good to keep here.  For push anyway.  We don't want every push to generate network traffic (unless the worker asks for it, I guess).

MaybeScheduleUpdate() sounds reasonable.  We don't *want* to trigger a whole lot of 304s if there are lots of these, but there shouldn't be lots of failures (ideally).  Bad workers are perhaps the main reason and a bad worker can generate a lot more work than a cache revalidation request.
Yeah, I think it's good to keep the 24-hour check for the success case. AIUI, the timer bypass is only for the case where the event handler throws, or the promise passed to `pushEvent.waitUntil` rejects.
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.