should blob URLs inherit controller from parent environment or environment that called createObjectURL()?

[wanderview]

Currently the spec says:

When the request’s url is local, if the service worker client's responsible browsing context is a nested browsing context or the service worker client is a worker client, the service worker client inherits the service worker registration from its parent browsing context’s environment or from the environment of a Document in the service worker client's global object's owner set, respectively, if it exists.

Is this correct for a situation like this?

// script running in window foo.com/uncontrolled.html
// no controlling worker

// register a service worker
let reg = await navigator.serviceWorker.register('sw.js', { scope: './controlled' });
await wait_for_State(reg.installing, 'activated');

// create a frame controlled by the SW
var f = await with_iframe('./controlled/frame.html');

// The controlled frame creates a blob:// URL
var blobURL = f.contentWindow.makeBlobURL();

// Create a worker from the blob URL.
// Should the worker be controlled by the frame's SW or uncontrolled?
// Spec currently says uncontrolled.
var w = new Worker(blobURL);

[mkruisselbrink]

I think the current spec is right, and parent environment makes the most sense.

I was going to say that with module workers, whose scripts can be cross-origin we'd have no choice since it really wouldn't make sense for the worker to be controlled by a cross-origin service worker, but then I realized that if I'm not mistaken a you'd still need CORS to be able to fetch a cross origin module worker, which won't work with blob URLs, so blob URL workers are still limited to same origin.

But I think that might still be an argument that it should to be the parent environment, since presumably we'd want to do the same for https cross origin module workers.

[wanderview]

I was less concerned about cross-origin blob URLs and more concerned about different service workers in different scopes for the same-origin. Inheriting origin is relatively straightforward, but origin does not map to a single controlling service worker unfortunately.

[mkruisselbrink]

Sure, but for cross-origin https URLs we won't have a choice but inherit the service worker from the parent (assuming we want those to be controlled at all). So I think it would be less confusing if the same rule is used everywhere something has to somehow derive a controlling service worker, rather than having different rules for https workers and blob: workers.

[wanderview]

Wait... if you use a cross-origin blob URL as a worker script, what is the origin of the worker?

[mkruisselbrink]

Wait... if you use a cross-origin blob URL as a worker script, what is the origin of the worker?

https://html.spec.whatwg.org/multipage/workers.html#script-settings-for-workers:concept-settings-object-origin

It inherits origin from the outside settings object.

[mkruisselbrink]

but I don't think cross origin blob URLs are allowed for workers, only cross origin https urls (since blob URLs don't support CORS).

[wanderview]

Worker scripts cannot be cross-origin with or without CORS, currently. I thought the blob URL always got its origin from the its creating context for some reason.

[wanderview]

So I would expect a cross-origin blob URL to fail to create a worker and the controller inheritance is moot.

For an iframe created from a cross-origin blob URL I would expect it to get the cross-origin. It seems like it cannot inherit the controller from the parent, though, because then the SW controller's origin would not match the controlled client's origin. It seems to me it should either get the controller from the context that called createObjectURL() or no controller.

[mkruisselbrink]

Worker scripts cannot be cross-origin with or without CORS, currently.

According to the spec module workers can be loaded from a cross origin URL (it's only "Fetch a classic worker scirpt" that sets mode to same-origin), unless I'm missing something? Sure, I don't think browsers have implemented that yet, but it is in the spec.

I thought the blob URL always got its origin from the its creating context for some reason.

Blob URLs do get their origin from their creating context, yes.

[mkruisselbrink]

For an iframe created from a cross-origin blob URL I would expect it to get the cross-origin. It seems like it cannot inherit the controller from the parent, though, because then the SW controller's origin would not match the controlled client's origin. It seems to me it should either get the controller from the context that called createObjectURL() or no controller.

Ah good point. Cross origin blob URL iframes I hadn't considered. That indeed blows a big hole in my argument, since there the opposite reasoning would apply...

[wanderview]

According to the spec module workers can be loaded from a cross origin URL (it's only "Fetch a classic worker scirpt" that sets mode to same-origin), unless I'm missing something? Sure, I don't think browsers have implemented that yet, but it is in the spec.

See: whatwg/html#3109

[mkruisselbrink]

See: whatwg/html#3109

Ah, I see. Yeah, it's helpful when discussing changes based on not-yet-reflected-changes in other specs to at least point out that you're relying on those not-yet-reflected-in-the-spec changes.

[wanderview]

Well, the spec was changed without any implementations following. So I think its more the spec that's out on a limb here.

Anyway, the iframe case shows the problem more clearly.

[mkruisselbrink]

Well, the spec was changed without any implementations following. So I think its more the spec that's out on a limb here.

I don't think the spec ever said anything else? At least every version of module workers I remember reading about in the spec allowed cross-origin URLs... Anyway, that doesn't really matter.

Anyway, the iframe case shows the problem more clearly.

Yeah, agreed. It still feels weird to me to inherit the controller from whoever created the blob URL, but if we want to let cross origin blob URLs be controlled we don't have a choice. I'm not convinced that we do want those to be controlled as it sort of feels like a weird thing where doing something in one place triggers something far away (i.e. that one document happens to load a blob URL in a worker suddenly triggers events in another origins service worker). It's probably harmless, and it sort of makes sense (and somebody creating blob URLs should already realize/be careful that loading that content will end up running in its own origin), but it feels like it might be unexpected...

Also inheriting controller from parent is nice and self-contained while inheriting controller from blob URL creator would require reaching out into other specs. But that is pretty minor of course.

So in summary, I like the simplicity of inheriting controller from the parent as long as the new client is in fact same origin, and otherwise just not having a controller, but I could be convinced that inheriting the controller from the blob URL's environment is the right thing.

[wanderview]

The other issue with trying to use the creation environment's controller is that the environment may be gone and its service worker unregistered. Although maybe the blob URL is also then considered dead?

Anyway, I guess parent if same-origin and no controller if cross-origin should be ok.

[mkruisselbrink]

The other issue with trying to use the creation environment's controller is that the environment may be gone and its service worker unregistered. Although maybe the blob URL is also then considered dead?

Yeah, that shouldn't be a problem. When the creation environment is gone the blob URL can't be fetched anymore.