← back to v154 · cors-enforcement-for-background-fetch
conformance · v154
v154 · cors-enforcement-for-background-fetch — conformance probe
7 assertions drawn from the spec. Each is a single contract the spec text makes. Pass/fail reflects what this browser executed; blocked means the contract was not run because it needs user mediation, hardware, or another unavailable precondition. Open the page in Chrome stable / canary / Firefox / Safari to compare.
0
pass
0
fail
0
blocked
7
total
| id | contract | kind | verdict | detail |
|---|---|---|---|---|
background-fetch-manager-exposed |
BackgroundFetchManager is the interface the feature governs. spec ↗ | typeof | … | |
registration-exposes-backgroundfetch |
backgroundFetch hangs off a ServiceWorkerRegistration, which is why the API needs a service worker at all. spec ↗ | exists | … | |
records-expose-responseready |
responseReady is where a CORS failure surfaces: the record exists, and reading its response is what is refused. spec ↗ | exists | … | |
secure-context-required |
Background Fetch is a secure-context API, which the demos depend on and which this page satisfies on localhost. spec ↗ | script | … | |
cross-origin-without-cors-is-not-readable-by-fetch |
The reference behaviour Background Fetch is being aligned to: a cross-origin no-cors fetch yields an opaque response the page cannot read. http://127.0.0.1 and http://localhost are different origins on the same server, which makes this checkable locally. spec ↗ | script | … | |
cross-origin-with-cors-is-readable-by-fetch |
The control for the assertion above: the same cross-origin URL WITH Access-Control-Allow-Origin is readable. If this failed, the previous assertion would prove nothing. spec ↗ | script | … | |
background-fetch-requires-user-activation |
backgroundFetch.fetch() is gated on transient user activation, so calling it from script with no gesture must reject. This is why the cross-origin demo asks the reader to click each button rather than running both itself. spec ↗ | script | … |