Re: [w3c/push-api] Retry push event (#300)

> In theory I can agree, but in practice we cannot change a core feature like this. Any small problem may have disrupting consequences on our business.

There's a plethora of techniques that can be used for safely rolling out changes - slow roll-out, (targeted) A/B testing, and so on. We can't really help you with that problem.

> I think that the event should offer a method like event.retryUntil(<Promise>) which ensures that multiple retries will be performed if the promise fails.

You're right that an explicit opt-in approach wouldn't break existing users, but there still are other concerns.

By sending a push message, developers have the ability to run JavaScript code on the user's device at a time of their choosing. This causes significant resource usage and is privacy sensitive, which is why various implementations require a notification to be shown.

Now suppose that my Service Worker, unbeknownst to the user, runs the following code:

```javascript
self.addEventListener('push', event => {
    // (1) Mine some cryptocurrency until the UA-defined time limit is reached.
    event.retryUntil(new Promise((resolve, reject) => {
        setTimeout(reject, GuessPushEventTimeLimit());

        // Iteratively do stuff here.
    }));

    // (2) Would timeouts be considered as failures?
    event.retryUntil(new Promise);
});
```

Suddenly the developer gets _N_ execution opportunities for each notification that's been shown, which is a multiplication factor for these concerns.

Variations on (1) could be to either retry forever until some UA-defined limit is reached, or execute this a few times before showing a notification. At that point we're effectively redesigning Background Sync, which is out of scope.

> I also believe that you can call ServiceWorkerRegistration.showNotification() inside a Background Sync. Am I wrong?

This is correct. Once permission has been granted, notifications can be shown from anywhere.

> stronger authentication with the application server (using normal sessions for example); the notifications can be displayed only if the user is actually logged in

That's a fair concern - take a look at the `cookiechange` event that's being proposed as part of the Cookie Store API, which enables you to observe deleted (and thus expired) cookies.

https://wicg.github.io/cookie-store/

> I think that you should define that more clearly (step by step) and allow notifications to be displayed indirectly by the push even (e.g. inside a sync)
> ...
> Then userVisibleOnly can be considered satisfied if: number of notifications > 0.90 * number of push received.

Because of the asynchronous and ephemeral nature of Service Workers, this actually is a _really_ hard problem. It depends on the conditions of the device, requirements of the operating system and user agent, and the user experience decisions made by the browser vendor.

To that end the specification doesn't detail _how_ `userVisibleOnly` works or what the conditions are - those are implementation specific.


-- 
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/300#issuecomment-419912851