backgroundfetchclick event handler is optional

[youennf]

A service worker that manages background fetches is not required to handle backgroundfetchclick events. Similarly, a bug in a backgroundfetchclick event handler (an early return, a rejected promise, a spin or a very long processing time) might trigger the same issue of user clicking on the User Agent UI showing bg fetches and nothing happens. This would like as if the User Agent has a bug.

This seems undesirable and I wonder whether User Agents could implement a fallback. If we look at the the fetch event, User Agents can always fallback to the network for instance.

One possibility would be to associate an URL to a bgfetch that could be used by the User Agent when appropriate. This URL could be the service worker registration scope URL. Or the scope URL could only be a default and the web application could provide its own URL (maybe with the problem/constraint that the URL should match the service worker registration).

If we go further down the road of this idea, we could think of removing backgroundfetchclick and only rely on this URL. We could probably provide hooks to allow User Agents to optimise its UI in case of a service worker wanting to reuse an existing page instead of loading the URL on a new page.

[youennf]

Another thing to consider is that the click event might be delayed until the service worker is activated. While this is somehow reasonable to assume delaying fetch until activated is fine (there is network latency), the expectation for a click event is to be much more reactive.

Similarly, if there are a lot of bgfetch that terminate, they are enqueued in the same queue. They might be fired before a click event, thus potentially delaying the click event handler execution noticeably. One way of solving this is for click events to be processed in a different queue.

[jakearchibald]

We could add an option to background fetch which provides a default URL, then, if that's provided backgroundfetchclick should call preventDefault to do something different. However, it seems inconsistent to do that here, but not notifications.

Are you seeing particularly long service worker startup times?

If we go further down the road of this idea, we could think of removing backgroundfetchclick and only rely on this URL.

This feels like a loss of functionality. For instance, if I'm uploading a group of photos, or a video, I might not know the destination URL of the upload before the upload begins.

Another thing to consider is that the click event might be delayed until the service worker is activated.

Is this likely? Feels like you'd be pretty unlucky to hit that.

[youennf]

However, it seems inconsistent to do that here, but not notifications.

Agreed this is very similar and we need a good click-to-service-worker model for both.

Are you seeing particularly long service worker startup times?

It is very dependent on the situation. If there is no page running for that origin, a new dedicated process needs to be spin, which can take up to a few hundred milliseconds. In terms of UI, this might already be long. Then comes the time to run JS, discover the various clients, before sending any UI order. That can be pretty long from a UI point of view.

Is this likely? Feels like you'd be pretty unlucky to hit that.

That may not be likely but we want to ensure a reliable experience whatever the state of the processes or service workers are. Especially since we are talking of the user clicking on User Agent UI. Ideally, it should be possible to not execute any website JS to properly react to the user click.

When clicking on a User Agent UI fetch entry, the user expectation is probably to have an existing page getting focus or a new page being shown. bgfetch could enforce this pattern as follows:

• When user clicks on the bgfetch entry, User Agent is responsible to select either an existing client or a new client. This selection is guided by the web site without running JS at the selection time
• User Agent creates a new client if needed, new client URL being the service worker registration URL if none was provided at creation of the bgfetch
• User Agent focuses on the selected client. At that point, the user is seeing a UI update and the speed of the next UI updates is less constrained
• User Agent sends the click event to the service worker, the event allowing to get direct access to the selected client
• The service worker manipulates the selected client at will
• If the service worker does not handle the event, default actions are done: for a new client, continue the load; for an existing client, reload

There are some benefits to this approach:

• A service worker starts running only if it has a client. This is a nice property from a design as well as implementation point of view.
• The User Agent UI reactiveness stays consistent
• A default behavior is defined and will lead to a functional user experience. Web site can enhance it with some dedicated service worker code
• User Agent is often the best one to select which client to use amongst several potential clients, especially in desktop environments where you might have multiple windows with multiple tabs

There might be different ways to allow a website tuning the client selection, for instance:

• A bgfetch option to set the client selection policy (always create a new client, select the best client whose URL is matching a given expression)
• A service worker API (Client maybe) or a page API to specify interest in being reused for specific events, potentially with some URL matching expression.

[jakearchibald]

There's a tension here between this and https://github.com/WICG/background-fetch/issues/145. The proposal there is to delay firing things like the success event until the service worker runs in reaction to user interaction. This will likely make the click reaction slower.