Intent to Implement: Background Fetch API

[Jennifer Harkness]

Contact emails

hark...@chromium.org, aw...@chromium.org, jakear...@chromium.org, pe...@chromium.org

Spec

https://github.com/jakearchibald/background-fetch

Design doc

Summary

Background Fetch API provides a service worker based download and upload mechanism which is persistent across service worker and browser restarts.

The system should provide a developer-controllable interface to schedule, query, pause, and cancel background downloads and uploads. After a scheduled fetch completes, the system will notify the developer of the outcome of the operation by sending an event to the service worker.

In progress downloads and uploads will be handled by the download manager and will be visible to users in a notification. The user will be able to pause and cancel actions from that interface.

Downloads and uploads should continue even if the developer's website is not loaded in a tab, and if Chrome is closed, the download should resume when Chrome opens again.

Motivation

If a developer wants to download a file, they can initiate the download or upload via fetch or XHR, but those fetches will be canceled if the user navigates away from the tab or the service worker is shut down.  Many developers have larger fetches that are needed for applications such as audio, video, photos, game levels, map packs, etc. which can’t be reliably fetched in the time available to a tab or service worker.

This API gives those developers the ability to queue up a fetch and then be evicted from memory without losing progress on the action. The fetch will continue while the app is not resident, and when the fetch is complete the service worker will be woken up and the app will be able to process the result.

Interoperability and Compatibility Risk

Standards discussion has already begun with web developers in the spec linked above. Additionally, we plan to release the feature using Origin Trials to get additional feedback before launching.

Edge: No signals

Firefox: No signals

Safari: No signals

Web developers: Positive

Ongoing technical constraints

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes, except WebView. Investigations are pending as to whether it is applicable in WebView. We expect that mobile platforms will be the primary users.

OWP launch tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=684578

Link to entry on the feature dashboard

https://www.chromestatus.com/features/5712608971718656

Requesting approval to ship?

No.

[Jennifer]

Please do take a look at the Design Doc for Background Fetch, but the actual Intent to Implement will be tracked in Blink.  (Direct link)

Sorry for the confusion,

Jen

[Richard Maher]

I would like to post the following: -

I find it inconceivable that such functionality or "feature" would be countenanced before background geolocation in Service Workers.

Whomever is allocating the development budget I beg to allocate funds on a more merits based criteria.

Cheers Richard Maher

What I don't post is: -

I am fed up to the back fucking teeth with the cult of "Offline first"! When will an adult start wading on to this Lord of the Flies island and start smashing heads :-(

OK yes, if I wasn't banned I would've posted it in it's entirety. "Guilty". 

Better ban me indefinitely, I think it's tourettesesque?

On Wednesday, January 25, 2017 at 2:14:10 AM UTC+8, Jennifer wrote:

Please do take a look at the Design Doc for Background Fetch, but the actual Intent to Implement will be tracked in Blink.  (Direct link)

Sorry for the confusion,

Jen

On Tuesday, January 24, 2017 at 6:08:08 PM UTC, Jennifer wrote:

Contact emails

[Richard Maher]

I apologize for the language! I honestly thought I was being filtered via 

"comm...@chromium.org"

 Please delete the offensive bits. Sorry again.