Re: [w3c/push-api] Properly defining `pushsubscriptionchange` (#228)

@beverloo

> We're seeing two cases in which this is relevant. (1) The UA hasn't connected to the Push Service at all in >9 months, so we forgot about them, and (2) we see a non-negligible amount of file I/O-related database corruptions in the client of our Push Service.

We've seen both cases, too. For case (1), our server is a lot more aggressive; it'll drop all subscriptions for a UA if it hasn't connected in 60 days. Those are stored locally, so we'll have full data.

Case (2) is fun. Our subscription storage mechanism is based on IndexedDB, and it's possible to induce corruption by switching between older and newer versions with the same user profile. Unfortunately, that breaks Push entirely (https://bugzilla.mozilla.org/show_bug.cgi?id=1258596): we can't retrieve subscription information at all.

We'd like to make this more robust in Firefox, so I can definitely see a case where we might be able to extract partial info. Considering your point that it's harder to make things non-nullable later, I'm totally OK with leaving it nullable.

> The `newSubscription` attribute would be NULL in the subscription revocation case, as well as in the subscription lost case when resubscribing fails due to insufficient knowledge (i.e. `applicationServerKey`) or networking errors.

After thinking about this a bit, I have a couple of questions. If the subscription has an `applicationServerKey`, is the browser allowed to resubscribe using that key? This would work if the browser stored the entire key (which Firefox does, to check if you're calling `subscribe()` with a different `applicationServerKey`), but not if it only stored a fingerprint. Or should we always leave it up to the service worker to resubscribe if the old subscription had an `applicationServerKey`?

For network errors: I assume the browser is allowed to retry if resubscribe fails, and only fire `pushsubscriptionchange` with `newSubscription` set to `null` if it exceeded the maximum number of retries, or if the server is permanently offline?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/push-api/issues/228#issuecomment-263367870