Test your knowledge: Workers & Interception

Question 1 of 6

The spec's IDL makes sendBeacon Window-only by…

It is an interface-definition decision — which interface gets the method — not a runtime check.

Answer options A checking typeof window at runtime in the method B defining it on the Navigator interface only — WorkerNavigator is not extended C a spec note that forbids workers from calling it D the Window-only IDL extended attribute

partial interface Navigator { boolean sendBeacon(...) }; — and WorkerNavigator is simply not extended. No runtime guard, no deprecation: the method just does not exist on the worker's navigator.

Review this lesson

Question 2 of 6

Can a Service Worker intercept a beacon sent by the page?

Beacon is just fetch with a badge — and the SW hooks all fetches in its scope.

Answer options A No — beacons bypass service workers entirely B Yes — beacons are fetches, so the SW's fetch event sees them C Only if the beacon is same-origin D Only when the SW was registered with a beacon scope

Beacons enter the same fetch pipeline, so a controlling Service Worker's fetch event handler receives them like any request. The SW can observe, modify, cache, or respond to beacons — but it can never originate one (no sendBeacon in the SW's own realm).

Review this lesson

Question 3 of 6

How does a Service Worker recognize that a request is a beacon?

The initiator type 'beacon' is NOT exposed to JavaScript — you must infer it.

Answer options A event.request.initiator === 'beacon' — exposed since Chrome 90 B The heuristic: keepalive === true AND method === 'POST' C A X-Beacon: 1 header the browser adds D event.request.url ends with /beacon

The initiator type lives in the fetch group but is not surfaced on Request. The reliable heuristic in the fetch handler: request.keepalive === true && request.method === 'POST'. It catches beacons AND keepalive fetches — the union the spec actually guarantees.

Review this lesson

Question 4 of 6

If a Service Worker `respondWith(...)`s to a beacon, what does the page learn?

Fire-and-forget means no one is listening on the page side.

Answer options A The beacon's true return flips to false B Nothing — the page has no response channel; only the SW sees the response C A beaconresponse event fires on navigator D The page's promise resolves with the synthetic response

sendBeacon's boolean was returned before the SW even saw the fetch event. The SW's respondWith affects only what the network layer records — the page never observes the response or the interception. The contract is asymmetric by design.

Review this lesson

Question 5 of 6

The canonical worker-context substitute for sendBeacon is…

The flag that lets a request outlive its context exists in workers too.

Answer options A postMessage to the page, which calls sendBeacon there B fetch(url, { method: 'POST', body, keepalive: true }) C A new XMLHttpRequest with async=false D navigator.sendBeacon polyfilled onto WorkerNavigator

fetch(keepalive) is available in worker contexts (Chrome 66+, Firefox 133+, Safari 11.1+ via the fetch API) and carries the same outlive-the-context guarantee. The recipe wraps it into a boolean-returning sendBeacon-shaped helper.

Review this lesson

Question 6 of 6

The `worker-safe.js` recipe exists because…

It is the integration lesson: detection + substitution + interception in one module.

Answer options A beacon libraries throw ReferenceError in workers B one code base must run in Window, Worker, and Service Worker realms with the right transport for each C Chrome deprecates sendBeacon inside cross-origin workers D workers cannot import ES modules

Window uses navigator.sendBeacon; workers use fetch(keepalive); a controlling SW may intercept either. worker-safe.js probes the realm once and exposes one boolean API that picks the right transport everywhere.

Review this lesson

Test your knowledge: Workers & Interception