Since it is implemented with a Runtime feature flag, it should be seen as
the ServiceWorker registration does not have the backgroundFetch field.
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/background_fetch/service_worker_registration_background_fetch.idl;l=12;drc=047c7dc4ee1ce908d7fea38ca063fa2f80f92c77

Then, they should be aware of the case as the lack of the field.


2025年11月25日(火) 17:46 Yoav Weiss (@Shopify) <[email protected]>:

> What would breakage look like? I agree that usage is very low, but would
> you expect users of those rare sites to be aware of breakage? Or would it
> just prevent those sites from optimizing some flows?
>
> On Tue, Nov 25, 2025 at 5:41 AM Chromestatus <
> [email protected]> wrote:
>
>> *Contact emails*
>> [email protected]
>>
>> *Explainer*
>> *No information provided*
>>
>> *Specification*
>> https://wicg.github.io/background-fetch
>>
>> *Summary*
>> Deprecates the Background Fetch API, which allows web applications to
>> download large files in the background, even if the user navigates away
>> from the page or closes the browser. Despite being available in Chrome
>> since version 74, the Background Fetch API has not seen wide adoption by
>> the developer community, with usage remaining consistently low, at less
>> than 0.00002% of page loads as of November 2025. Given the low adoption
>> rate and the significant engineering effort required to maintain the API
>> and address ongoing security issues, it is being deprecated. Developers are
>> encouraged to explore alternative solutions for managing large file
>> downloads.
>>
>> *Blink component*
>> Blink>ServiceWorker
>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EServiceWorker%22>
>>
>> *Web Feature ID*
>> background-fetch <https://webstatus.dev/features/background-fetch>
>>
>> *Motivation*
>> The Background Fetch API has been available in Chrome since version 74.
>> However, it has not seen wide adoption. Usage metrics show that the feature
>> is used in less than 0.00002% of page loads as of November 2025. Given the
>> low usage, the ongoing engineering effort to maintain the Background Fetch
>> API and address security issues is no longer justifiable. For developers
>> who need to provide users with the ability to download large files, there
>> are several alternatives: - For simple file downloads, developers can
>> provide a standard download link. - For more advanced use cases, such as
>> providing offline access to large files, developers can use the Fetch API
>> within a Service Worker to download and cache the necessary resources. This
>> approach provides developers with greater control over the user experience.
>>
>> *Initial public proposal*
>> *No information provided*
>>
>> *TAG review*
>> *No information provided*
>>
>> *TAG review status*
>> Not applicable
>>
>> *Risks*
>>
>>
>> *Interoperability and Compatibility*
>> The interoperability risk of removing the Background Fetch API is low.
>> The API has not been implemented by Firefox or Safari, and there have been
>> no signals from either to indicate that they intend to do so. As a result,
>> removing this API from Chrome will not cause interoperability issues, as it
>> is not a feature that is part of the interoperable web platform. The
>> compatibility risk is also minimal. Usage of the Background Fetch API has
>> remained consistently low, at less than 0.00002% of page loads as of
>> November 2025. Because of this extremely low usage, the number of websites
>> that will be affected by this removal is very small.
>>
>> *Gecko*: No signal (
>> https://github.com/mozilla/standards-positions/issues/30)
>>
>> *WebKit*: No signal (
>> https://github.com/WebKit/standards-positions/issues/149)
>>
>> *Web developers*: No signals
>>
>> *Other signals*: TAG: https://github.com/w3ctag/design-reviews/issues/279
>>
>> *Ergonomics*
>> The Background Fetch API is tightly coupled with the Service Worker API.
>> It is accessed through the backgroundFetch property of a
>> ServiceWorkerRegistration object. Developers using this API would also
>> likely use the Fetch API to create the Request objects for the download and
>> the Cache API to store the downloaded responses. The API is designed to be
>> asynchronous and to operate in the background. The main fetch() method
>> returns a Promise, and the download process is managed by the browser, off
>> the main thread. This design avoids blocking the main thread and is
>> intended to improve performance and battery life for large downloads
>> compared to keeping a service worker alive for a long-running fetch.
>> Therefore, the API's usage does not inherently pose a performance risk that
>> would make it difficult for Chrome to maintain good performance. The
>> deprecation is due to low adoption and high maintenance cost, not because
>> of ergonomic or performance issues in its design.
>>
>> *Activation*
>> This change is a deprecation and removal of an existing API. The primary
>> risk is the impact on developers who are currently using the Background
>> Fetch API. However, the "activation" risk for this removal is minimal. The
>> API has seen extremely low adoption since its introduction in Chrome 74,
>> with usage below 0.00002% of page loads. This indicates that very few
>> developers will be required to take action.
>>
>> *Security*
>> The removal of the Background Fetch API reduces the overall attack
>> surface of the browser and mitigates existing security issues associated
>> with maintaining the feature.
>>
>> *WebView application risks*
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>> *No information provided*
>>
>>
>> *Debuggability*
>> *No information provided*
>>
>> *Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, ChromeOS, Android, and Android WebView)?*
>> No
>>
>> *Is this feature fully tested by web-platform-tests
>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?*
>> No
>>
>>
>> *Flag name on about://flags*
>> *No information provided*
>>
>> *Finch feature name*
>> BackgroundFetch
>>
>> *Rollout plan*
>> Will ship enabled for all users
>>
>> *Requires code in //chrome?*
>> False
>>
>> *Tracking bug*
>> https://crbug.com/460293588
>>
>> *Estimated milestones*
>> Shipping on desktop 146
>> Shipping on Android 146
>> Shipping on WebView 146
>>
>> *Anticipated spec changes*
>>
>> Open questions about a feature may be a source of future web compat or
>> interop issues. Please list open issues (e.g. links to known github issues
>> in the project for the feature specification) whose resolution may
>> introduce web compat/interop risk (e.g., changing to naming or structure of
>> the API in a non-backward-compatible way).
>> *No information provided*
>>
>> *Link to entry on the Chrome Platform Status*
>> https://chromestatus.com/feature/5074579353632768?gate=6606728540061696
>>
>> This intent message was generated by Chrome Platform Status
>> <https://chromestatus.com>.
>>
>> --
>> 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 [email protected].
>> To view this discussion visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6925253c.050a0220.107b62.0899.GAE%40google.com
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6925253c.050a0220.107b62.0899.GAE%40google.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
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 [email protected].
To view this discussion visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPNB-6XReNOmeKf97p49h0AkdUSqyUrhnmCi30gX-X6KKGb9HA%40mail.gmail.com.

Reply via email to