Following @zetafunction's comments on #3714 (comment), it seems like there are multiple different cases here that need to be handled (assuming that active service worker and origin should always be in sync):

• srcdoc iframe document's origin is always the same as the parent.
• about:blank documents seems to vary based on whether they are "initial" vs. "non-initial". For "non-initial", it may differ if "script was involved". TBH, I'm not 100% sure what that means.
• javascript: documents - I think it means that they inherit the origin from the about:blank document that they navigated, but would love confirmation that I'm reading it right.
• data: URLs are always an opaque origin, so we should make sure that their subresources (if any) would not be intercepted. (That probably already happens, just need to avoid breaking it)

It was also pointed out by @kinu that we need to make sure we take the iframe's sandbox attribute into account.

@yoavweiss We probably need to try to write some test cases for each one so we can reason about them. I also am not sure all the cases for "non-initial about:blank".

Also, there are blob: URLs which inherit their origin from the window that called URL.createObjectURL(). There is an open spec issue about where the service worker should be inherited from, though. See w3c/ServiceWorker#1261.

There are some tests for initial about:blank and about:srcdoc here:

https://github.com/web-platform-tests/wpt/blob/master/service-workers/service-worker/about-blank-replacement.https.html

There are some tests with data and blob URLs in here:

https://github.com/web-platform-tests/wpt/blob/master/service-workers/service-worker/local-url-inherit-controller.https.html

Looks like we need to add non-initial about:blank and javascript: URL testing.

I asked around a bit regarding "non-initial about:blank". Some cases to consider:

• iframe A triggers the navigation of iframe B using <a target="B" href="about:blank">. That should result in an iframe B with iframe A's origin.
• iframe A can use parent[indexOfB].location = "about:blank". This should also result in an iframe B with iframe A's origin.
• iframe B could set its own location to "about:blank". In this case it should preserve its own origin.

Does that sound right @annevk?

An open question is if we should always inherit the service worker controller from the parent or from the source of the origin inheritance. There is some discussion of this in w3c/ServiceWorker#1261.

Is there some way that we can sync the active service worker with the origin without handling all those cases one by one? I'm afraid that doing the latter might be error-prone and hard to maintain. We can do it if there's no alternative, but it might be worth while to try to come up with one

I think it would be wonderful to have a "inherit stuff" algorithm that brought forward origin, service worker controller, etc. Maybe it would include stuff like CSP as well, etc. Then specs could just be written to "inherit stuff" and it would get everything.

The question is, do we currently inherit everything consistently today? And if we don't, can we align them all to inherit consistently?

This definitely seems like a bigger set of refactoring to the spec, though.

@yoavweiss Are you working on this? If not, is that okay If i take over it to complete.

@yoavweiss Are you working on this? If not, is that okay If i take over it to complete.

I'm not actively working on this. Thanks for taking it on! :)