Background Fetch

[marcoscaceres]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Background Fetch
• Specification or proposal URL: https://wicg.github.io/background-fetch/

Other information

An API to handle large uploads/downloads in the background with user visibility.

[annevk]

Per w3ctag/design-reviews#279 Google plans on shipping this soonish. Has anyone looked at this in detail?

cc @wanderview

[asutherland]

From the ServiceWorkers TPAC F2F, Chrome is about 4 weeks out from an intent-to-ship on this. From the Gecko DOM workers & storage team, this seems like a reasonable API to us but the earliest we could get to it is 2019Q1 and Q2 is likely more realistic unless the network team wants to pick it up.

[annevk]

Given https://wicg.github.io/background-fetch/#privacy-and-bandwidth-use it'd be useful to get some security UX feedback on this as well, e.g., from @johannhof.

[annevk]

Sorry for neglecting to update this issue. In contrast with "background sync" this is effectively "background downloads" under a different name as I understand it.

Based on private conversations (i.e., not my idea) a model that might work here is that we treat these entirely as downloads (requiring user gesture, probably restrict to first parties, etc.) and only notify the service worker of completion of these downloads if it happens to be still open or when the user next visits. I.e., do not give it the opportunity to run script in the background.

[tomayac]

[T]his is effectively "background downloads" under a different name as I understand it.

Despite the maybe misleading name, this is for downloads and uploads. It’s made clear in the spec’s abstract.

[codehag]

@asutherland would you be able to take another look at this? It still hasn't been moved to a standard, but if this is worth implementing, we'd like to communicate with google about moving this to a proper spec body.

[marcoscaceres]

Filed a webkit position also WebKit/standards-positions#149

[asutherland]

I was pinged via other channels; from the perspective of our DOM: Workers & Storage team:

• The API is useful.
• I think we have consensus around what needs to happen to make Gecko and WebKit happy in terms of deferred notifications so that a ServiceWorker is never woken up if there is not an active tab for the origin/storage key. Specifically, @annevk's comment above made as a Gecko contributor at Background Fetch  #30 (comment) still holds, as does his more recent comment as a WebKit contributor at Background Fetch WebKit/standards-positions#149 (comment) (although he discusses a randomized delay as a possibility; I don't think Gecko is okay with that). I think the canonical issue for this meta-issue is background fetch can start service workers WICG/background-fetch#145 and is still open and needs to be addressed.
• I think we have consensus that background fetch should be moved to the ServiceWorkers WG, especially since it was originally discussed in this venue. WebKit in particular indicated a desire for this in their standards-positions on background fetch at Background Fetch WebKit/standards-positions#149 (comment)