pushsubscriptionchange (was pushregistrationlost) use case about push-api HOT 9 CLOSED

User agent may note that it has missed a push message, e.g. if messages are numbered in the protocol between push server and user agent and it receives message number 54 after number 52. An error message indicates to the webapp that something went wrong. pushregistrationlost is maybe not the best wording. If I recall correctly it used to be pusherror and was changed into pushregistrationlost at some point

from push-api.

The numbering thing is not something that I'd rely on.

There are two reasons this might occur: either the push server can't be contacted because it is broken; or the registration might become invalid (either because the server decides it needs to, or it might just have a time limit).

Clients learn of this by either being unable to talk to the push server, or by receiving signals from the push server.

from push-api.

You can lose registrations (pushregistrationlost event) or messages (messagelost event), these are separate use cases and we should have separate events for them. I think that was the conclusion of issue #18.

Currently I'm not sure Chrome will ever fire pushregistrationlost because it does not poll GCM to verify validity of its registrations. Polling seems wasteful of battery. The webapp will never be notified by the push system because it does not know who to notify. When the application server attempts to push new messages to the push server, the push server will reject for unknown registrations. So the application server will eventually know, and it can tell the webapp through another mechanism e.g. at webapp startup.

Using a GCM based implementation we might be able to fire messagelost. There is a limit of 100 pending messages on the GCM server and when it is exceeded all are dropped. The client will be informed of this: https://developer.android.com/google/gcm/adv.html

from push-api.

I wasn't suggesting that you do poll. I'm asking whether you care about reporting the fact that GCM itself might be unreachable. I assume that you have the ability to learn about that.

This might only be a transient problem, but I've used other systems where a registration is homed on a particular instance, and while it can be recovered in some circumstances if that instance goes down, not all errors can be recovered immediately. That requires recreation of registrations.

That might not be a problem with GCM short of a complete catastrophe, but I wouldn't say that this is a guarantee.

from push-api.

Registration 'lost' and GCM reachability are different issues. For 'lost' registration - it affects a very small percentage of devices, and the 'support' solution is to ask for a factory reset to recover, in part because we lack the notification (and many apps didn't implement it properly in C2DM ).
An even smaller number of devices have a 'cloning' problem - where backup/reset was used. I don't know if browsers profile dir is based on hardware id, but on android a rooted device can be cloned - and the clone will have same registration IDs, so messages go randomly to one of the clones.

Reachability of the push server should be a separate issue - seems very useful to provide, but some care is needed - the connection status events can't be broadcast to all apps ( too frequent, memory/load issues when you have lots of apps ), apps need to query and register a listener for connection events.

from push-api.

Out of interest, assuming that pushsubscriptionlost event is used by a push service, what is the process to re-register?

I'm assuming the expiration of a push subscription does not remove the permission to re-request a new push subscription ID, however, I can't see any mention of making the PushManager accessible to the ServiceWorkerGlobalScope (although I may be thinking the wrong way), is this intentional?

from push-api.

The ServiceWorkerGlobalScope has readonly attribute ServiceWorkerRegistration registration.

from push-api.

The Chrome implementation bug is here: https://crbug.com/437677

from push-api.

Thanks @mvano was looking at w3 spec and then obviously missing that bug. Tracking that.

from push-api.