v135 · service worker
Create service worker client and inherit service worker controller for srcdoc iframe
srcdoc context documents were not Service Worker clients and were not covered by their parent’s Service Worker. That caused inconsistencies: Resource Timing could report URLs loaded by the inline document, but the Service Worker could not intercept those requests. Chrome 135 fixes this by creating Service Worker clients for srcdoc iframes and making them inherit the parent document’s controller.
concepts
-
srcdoc SW client
The basic inheritance demo: a
srcdociframe inside a SW-controlled page reports a controller and is interceptable. -
clients.matchAll visibility
The interop bug from the spec issue: pre-135, a
srcdociframe was a Resource Timing entry but not a SW client. This demo shows it now counts. -
srcdoc client tree probe
Spin up multiple inline
srcdociframes and ask the parent's service worker forclients.matchAll(). Each frame shows up as controlled (Chrome 135+) or isolated. -
Fetch Intercept Demo
Register a Service Worker, then trigger a
fetch()from inside asrcdociframe. In Chrome 135+ the SW intercepts it; pre-135 the fetch bypasses the SW entirely. Side-by-side with a regularsrciframe that has always been controlled. -
Nested srcdoc SW inheritance
Chrome 135 makes
srcdociframes real SW clients — but how deep does inheritance go? This probe steps through a three-level hierarchy: top page (depth 0), a srcdoc iframe (depth 1), and a srcdoc-inside-srcdoc (depth 2). All three should report the same SW controller.
why it shipped
srcdoc iframes are commonly used for sandboxed previews, email rendering, editors, and generated documents. Before Chrome 135, those inline documents could make network requests without passing through the Service Worker that controlled the parent page, which broke offline, caching, and request-rewrite patterns. The Chrome 135 change aligns srcdoc with other same-origin frame clients so the worker can see and handle those requests.