v154 · background fetch
What the change means for your code
If a background fetch worked before Chrome 154 and stops working now, it is one of three things — and the useful part is that all three are decidable from the URL list before you ship. Paste yours in.
Audit a URL list
| URL | relative to this page | what changes | what to do |
|---|
The three ways it breaks
| cause | symptom in the worker | fix |
|---|---|---|
Cross-origin with no Access-Control-Allow-Origin |
The fetch may report success, but record.responseReady gives you an opaque or failed response — you cannot read the bytes. |
Add the header at the origin serving the file, or proxy it through your own. |
| A request that now needs a preflight | The record fails outright. Custom headers and non-simple methods trigger an OPTIONS that was previously skipped. |
Answer the preflight, or drop the header that triggers it — a background download rarely needs one. |
| A local or loopback address | Blocked by Local Network Access, which now applies here too. | Declare the address space and take the permission, as any other fetch would. |
All three have the same shape: the request was always subject to these rules on paper, and Background Fetch was the one path that skipped them. Anything that breaks was relying on the gap — which is why the fix is never "work around the enforcement" and always "do what a normal fetch would have needed".