Intent to Ship: Background Fetch

[Mugdha Lakhani]

Contact emails

raya...@chromium.org, na...@chromium.org, jakear...@chromium.org, pe...@chromium.org

Explainer

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

Spec

https://wicg.github.io/background-fetch/

Tag Review

https://github.com/w3ctag/design-reviews/issues/279

Test Website

https://backgroundfetch.com/ (code here)

Summary

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

The system provides 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 are 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.

Limitations

We don’t support background fetch requests requiring CORS preflight at this time. Work on this is in progress.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/Ia9_-CVrl1U/jEBQGVv_BQAJ

Origin Trial feedback summary

The API has been available through origin trials since Chrome 71. No negative feedback has been received.

Will this feature be supported on all five Blink platforms supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?

Yes, except WebView.

Demo link

Demo page. Video.

Note: Need to enable chrome://flags/#enable-experimental-web-platform-features

Debuggability

Background Fetch initiated downloads are clearly identified at chrome://download-internals.

rayankans@ is working with the DevTools team to expose background behavior in Chrome, which will be used for Background Fetch as well.

Risks

Interoperability and Compatibility

As this is a new feature which Chrome is leading with, we have solicited community feedback and submitted a complete WPT test suite.

Interest from other stakeholders is as follows:

Edge: Positive

Firefox: Positive

Safari: No signal

Web developers: Positive (Facebook and LinkedIn are super interested in the uploads support.)

Compatibility isn’t an issue. We don’t foresee this breaking any existing websites as it’s a new feature.

Ergonomics

No adverse effects on Chrome performance are expected.

We recommend developers to use the Permissions API to check for background-fetch permission before starting a background fetch, and expect these two APIs to often be used together.

Activation

The API can be used immediately and easily when shipped. The explainer has examples.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

Yes. Test suite here.

Entry on the feature dashboard

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

[Yoav Weiss]

LGTM1

On Mon, Mar 4, 2019 at 3:22 PM Mugdha Lakhani <na...@chromium.org> wrote:

Contact emails

raya...@chromium.org, na...@chromium.org, jakear...@chromium.org, pe...@chromium.org

Explainer

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

Spec

https://wicg.github.io/background-fetch/

Tag Review

https://github.com/w3ctag/design-reviews/issues/279

Test Website

https://backgroundfetch.com/ (code here)

Summary

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

The system provides 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 are 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.

Limitations

We don’t support background fetch requests requiring CORS preflight at this time. Work on this is in progress.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/Ia9_-CVrl1U/jEBQGVv_BQAJ

Origin Trial feedback summary

The API has been available through origin trials since Chrome 71. No negative feedback has been received.

Any positive feedback from the origin trial? Any learnings? Happy customers?

 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BPd-jfUQ%3DbAphs527pD47%2BkBkOaxP9%2BArtwZS08S31UVn17ZQ%40mail.gmail.com.

[Yoav Weiss]

On Mon, Mar 4, 2019 at 3:22 PM Mugdha Lakhani <na...@chromium.org> wrote:

Contact emails

raya...@chromium.org, na...@chromium.org, jakear...@chromium.org, pe...@chromium.org

Explainer

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

Spec

https://wicg.github.io/background-fetch/

Tag Review

https://github.com/w3ctag/design-reviews/issues/279

Test Website

https://backgroundfetch.com/ (code here)

Summary

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

The system provides 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 are 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.

Limitations

We don’t support background fetch requests requiring CORS preflight at this time. Work on this is in progress.

Will developers have a clean way to know that this is not currently supported? Will they know that it is, once support is added?

 

[Daniel Bratell]

LGTM2

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEjPO%3DA_fGtdD2xxKUadz5SsbP1KtHHToAPaW7b8VmG8ew%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

[Chris Harrelson]

LGTM3!

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.zx91zhjcrbppqq%40cicero2.linkoping.osa.

[Mugdha Lakhani]

Thanks!

Yoav -- Happy customers indeed. One learning was that we need a better way of debugging the API, and hence rayankans@ is working on exposing major events (plus metadata) through DevTools. Through origin trials, we also found a few bugs around edge-cases in a component we depend on, and fixed them.

Daniel -- If CORS preflight is needed, we simply fail the background fetch with a catch-all error ("fetch-error") so the developers won't know it has failed because of this limitation. But we're working on adding support for this, and all the interested parties we've spoken to so far tell us that the absence of CORS preflight support isn't an issue for them.

Cheers,

Mugdha

[Jxck Jxck]

Hi

I tried this API, and register bgfetch task from window works fine.

but register task from sw doesn't works.

1. register bgfetch task from service worker (via 'sync', 'periodic-sync' etc)

2. task registered successful but suspended.

3. if resume from system UI, fetch starts.

I wanna register bgfetch in background, and also download in background.

I tried this in

- chrome 81

- on android R emulator

- on MBP catalina

is there any restriction for bgfetch registered from service worker (not from window) ?

thanks

Jxck

2019年3月4日月曜日 23時22分23秒 UTC+9 Mugdha Lakhani:

[Rayan Kanso]

Hi,

Yes this is intentional. Background Fetches initiated anywhere other than the top level window start in a suspended state.

If you have other issues or feedback, please file a bug using crbug.com with the Blink>BackgroundFetch component.

Thanks,

~Rayan

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fe0dd4f1-7c7a-4ad1-a519-189fe8267560%40chromium.org.

[block.rxc...@gmail.com]

Thanks Rayan.

> Yes this is intentional. Background Fetches initiated anywhere other than the top level window start in a suspended state.

then I wanna discuss about this spec, not a crbug.

if that is intentional, is that behavior based on (bgfetch, pbs, sw) spec ?

or based on chrome own security/privacy considerations ?

if other browser implements bgfech & pbs, they should behave same ? or depends on their intervention ?

now I'm trying build Podcast app over PWA.

Podcast usually sync xml feed in background (pbs)

and if feed includes mp3, fetch in background (bgfetch)

I wanna discuss this use-cased should covered by bgfetch + pbs or should not.

thanks

Jxck

2020年4月14日(火) 19:00 Rayan Kanso <raya...@google.com>:

[Rayan Kanso]

Hi,

Here's a relevant excerpt from the spec:

The user agent may also consider setting bgFetch’s paused flag if the user is on a metered connection, or the background fetch was started in the background.

Different browsers can implement this part differently. If you have spec issues you can file them here: https://github.com/WICG/background-fetch/issues/. 

Thanks,

~Rayan

[Rayan Kanso]

Hello,

Uploads have been supported for a few years now. You can try it out on backgroundfetch.com (by ticking the Fetch request with body option).

If you are getting fetch errors, it could be because this is a cross-origin request? Make sure you have the appropriate CORS headers in place to allow for that.

Thanks,

~Rayan

On Tue, Oct 11, 2022 at 8:13 AM maasa yoshida <maasa...@gmail.com> wrote:

Hello,

I am eagerly awaiting support for the upload functionality of this API.
It would be a great experience if users of my application could close a tab while uploading a huge file and the upload would continue.

Am I correct in understanding that uploading is not yet implemented right now?
(I tried it at hand and got a "fetch-error". I thought it must be because preflight requests are not yet supported.)

I would like to know if there are any plans regarding the implementation of uploading.
Or is there any reason why it cannot happen?

Thanks,

yoshiko

2020年4月14日火曜日 20:06:08 UTC+9 raya...@google.com:

[maasa yoshida]

Hello,

I am eagerly awaiting support for the upload functionality of this API.
It would be a great experience if users of my application could close a tab while uploading a huge file and the upload would continue.

Am I correct in understanding that uploading is not yet implemented right now?
(I tried it at hand and got a "fetch-error". I thought it must be because preflight requests are not yet supported.)

I would like to know if there are any plans regarding the implementation of uploading.
Or is there any reason why it cannot happen?

Thanks,

yoshiko

2020年4月14日火曜日 20:06:08 UTC+9 raya...@google.com:

Hi,

[maasa yoshida]

Thanks Rayan-san.

After reviewing it, I found a mistake in my configuration -- I was able to send a POST Request with a body(upload)! Great feature. Thank you!
Perhaps the "The Origin Trial launched in Chrome 71 only supports requests without a body," in https://chromestatus.com/feature/5712608971718656 is out of date?

Thanks,

yoshiko

2022年10月11日火曜日 23:23:37 UTC+9 raya...@google.com: