Define the lifetime of a blob URL created inside a service worker

[ehsan]

Right now in Gecko at least we tie the lifetime of such URLs to the Worker or SharedWorker that created them, but doing the same (as in, invalidating the blob URL when the service worker goes away) seems wrong, since that can happen at any time at UA's discretion.

How should we handle this?

One option that comes to my mind right now is keeping those URLs valid until the service worker that registered them is unregistered.

[jakearchibald]

I think Gecko's current behaviour is correct. Yes, it may get GC'd when the SW closes, but same with variables. If you want a long term way to store a response, the caches api is the way to go right?

Tieing it to registration feels wrong as it would need to survive browser shut down.

What is the current behaviour breaking? I'm wondering if a way to access items in the cache api by url may be a better solution.

[annevk]

We should maybe restrict this API inside service workers since it's a giant memory leak. And only allow the one-time-minting variant.

[jakearchibald]

Is it a giant memory leak if the data is GC'd when the SW terminates?

[annevk]

Depends on whether service workers will forever terminate quickly. It seems better to simply not offer APIs that are known to be problematic.

[jakearchibald]

@annevk I really don't think this is a problem any more than it is on pages. Service workers are generally not alive longer than pages.

[annevk]

Right, that argument was made, and the argument against was that it might not remain that way. I guess the other question is why we need blob URLs in service workers since we can just use Request/Response objects.

[jungkees]

Need a resolution. Would like to discuss at the f2f.

[mfalken]

Implementor feedback from Chrome: if we continue to allow blob URLs in service workers, tieing the lifetime to the service worker (i.e., the execution context that created it, not the registration) sounds good. That's what Chrome does already.

[jakearchibald]

F2F resolution: remove createObjectURL

[jungkees]

@annevk Is it better to make URL.createObjectURL(blob), URL.createFor(blob) and URL.revokeObjectURL(url) explicitly throw in File API spec?

[annevk]

@jungkees no, I would get the File API specification to use [Exposed=] similar to how XMLHttpRequest does that for e.g., responseXML, to hide these from service workers.

[wanderview]

Gecko bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1264182

[jungkees]

Closing with w3c/FileAPI#31 merged.

[inexorabletash]

Blink tracking bug: https://bugs.chromium.org/p/chromium/issues/detail?id=604951

I filed w3c/media-source#67 since MediaSource has createObjectURL as well.

MediaStream had it as well at some point but it's been removed from the spec.