My understanding is there's an implementation underway. Is there really no time pressure and/or deadline you'd like us to work under?

We're aiming to send an intend to ship in July/August, so it's a little more pressing that I initially thought.

How can you ship when the draft has substantive issues, such as the one below "response failed due to a failed CORS check"? (I don't think we should expose such a failure to content.)

I do need to get a move on with the spec 😢. Trying to devote more time to it.

Seems like the explainer switched branches: https://github.com/WICG/background-fetch/blob/master/README.md

Hi! Just getting my feet wet with this spec, so I apologies if my mental map is incomplete... Here's a few points of discussion I found in my first read:

The optional downloadTotal dictionary member misled me by it's name. I think having it called something like doNotExceed would better map to the use case than a pre-predicted estimate of the download total (and then leave the UI stuff to the UA to figure out (which it should know by the server responses, etc.)

The registration.backgoundFetch object is similar to a map in many respects. I wonder if some APIs could align better? E.g., ids are the keys to the various ongoing fetches. getIds() is like keys()... but set()` isn't a great match for initiating a fetch so I'm less convinced to go all the way aligning the names :).

In the spirit of not needing to re-activate the browser code to do UI updates, I'd like to suggest we drop updateUI in favor of pre-declaring these strings at the time of the background fetch start. Probably you just need to care about three states: downloading (icon, title), finished (icon, title), and error/canceled (icon, title). It's not as generally powerful, but can make the UI transitions more smooth by avoiding the round-trip to the client for the various state transitions. (Also the download/upload states aren't really expected to change in an ad-hoc manner.)

The optional downloadTotal dictionary member misled me by it's name. I think having it called something like doNotExceed

doNotExceed kinda loses context. Eg, does it include upload bandwidth?

(and then leave the UI stuff to the UA to figure out (which it should know by the server responses, etc.)

If you're downloading a DASH-style movie it could be 1000s of resources. It's going to take a long time for the browser to know much about the size.

The registration.backgoundFetch object is similar to a map in many respects.

The main difference is it's async. I'd like to make it an async iterator at some point.

In the spirit of not needing to re-activate the browser code to do UI updates,

The browser needs reactivated anyway so the responses can be handled/read/moved. I kinda like the idea of specifying this stuff ahead of time, but it feels like it loses functionality for not much gain.

I've just published an article about my exploration of what we have in Chrome Canary M72 at the moment: https://medium.com/@webmaxru/background-fetch-api-get-ready-to-use-it-69cca522cd8f

From this post: "The downloadTotal property we pass during the background fetch registration is the total number of bytes of the whole set. It’s also optional. If passed, it works as a guard — we’ll get backgroundfetcherror event in the service worker if the total size of the resources is larger. Also, it’s a good helper for our UI to show the correct download percentage if needed. Unfortunately, there is another bug: at least on Mac OS this number can’t be larger than 2147483647 (2 GB) which is the maximum size of one file in the file system but it’s intended to be the maximum total size of the whole set. I’m going to submit a bug to the Chromium Bug Tracker about this. Meanwhile, if the total set size doesn’t bypass 2GB (like in our case) our calculations are correct."

But I might be wrong in my assumptions :)

Your assumptions are correct. The spec defines the maximum of downloadTotal to be 18,446,744,073,709,551,614, so it's a Chrome bug.

@webmaxru you might also be interested in https://bgfetch-http203.glitch.me/.

@webmaxru you might also be interested in https://bgfetch-http203.glitch.me/.

Hard to imagine the better usecase! I plan to build a PoC of bgfetch automation tool, maybe this will end up as a plugin for Workbox - will use podcast app as a guinea pig :)

Article from G: https://developers.google.com/web/updates/2018/12/background-fetch

Have re-read the spec and associated resources, and I'm feeling more comfortable with the design ;-).

In the explainer you note that the UA should take steps to ensure that the content that originates from the web app is distinctly separate from the trusted UI elements as rendered by the UA. Another concern that led to browsers all-but-removing the rendering of beforeunload's status message, is that fields like "title" are potential attack surface. May want to make of note of that in the Security and Privacy section of the spec as well to be sure implementors are aware.

Have filed the above issue. All others on the call today supported closing the issue. Thanks so much for the TAG review, and we hope to be of service again soon (Come on back, ya'll!)

Thanks TAG! The review was genuinely useful & I'm looking forward to the next one.