Intent to Deprecate and Remove: Blob URLs created in Service Workers

[Joshua Bell]

Primary eng (and PM) emails

jsb...@chromium.org

Summary

Remove URL.createObjectURL, URL.revokeObjectURL from Service Workers

Motivation

Service Worker inherited URL minting methods for blobs (URL.createObjectURL, URL.revokeObjectURL) since they were exposed to Window and Worker contexts by default. This was raised as an issue [1] since the URL lifetime is tied to the lifetime of the creation context, but SWs are (by design) shut down promptly. The resolution to the issue was to forbid these methods in SW contexts.

The relevant spec (File API) was updated[2]. I'm following up with MediaSource [3] as well, assuming the same logic applies.

[1] https://github.com/slightlyoff/ServiceWorker/issues/688

[2] https://w3c.github.io/FileAPI/

[3] https://github.com/w3c/media-source/issues/67

Compatibility Risk

Only affects Service Workers, and use of the URLs would have been flaky at best.

Gecko is also removing the methods.

Alternative implementation suggestion for web developers

In a Service Worker, the model is inverted - you're almost certainly servicing a fetch from a page via a FetchEvent with a URL that you want to intercept and provide a response for. In that case you can simply respondWith(new Response(blob)).

Usage information from UseCounter

n/a - we're removing ASAP

OWP launch tracking bug

n/a - we're hoping no-one even noticed these were present...

Entry on the feature dashboard

n/a - these aren't the droids you're looking for...

Requesting approval to remove too?

Yes.

[Chris Harrelson]

LGTM1

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Rick Byers]

Seems likely to be low risk, but in general I don't like relying on "hope" when it comes to potentially breaking sites. It doesn't seem impossible to me that some library code (designed for non-worker scenarios but used in a SW) is somehow depending on these APIs existing, right?

Perhaps it's not too late to get a deprecation warning (with UseCounter) merged back to 51, then you can remove in trunk after a few days of data confirms there's no usage in beta. WDYT?

[Marijn Kruisselbrink]

Unfortunately use counters aren't supported yet in shared and service workers. So getting data would be significantly harder than that.

[Chris Harrelson]

On Fri, Apr 22, 2016 at 5:14 PM Marijn Kruisselbrink <m...@chromium.org> wrote:

Unfortunately use counters aren't supported yet in shared and service workers. So getting data would be significantly harder than that.

Is there a plan to do it soon? It's not good at all to fly blind like this.

[Marijn Kruisselbrink]

I believe the worker team has it as one of their okr's this quarter. I'm sure they'll correct me if I'm wrong.

[Matt Falkenhagen]

Yes, this is on our goals for Q2. The tracking bug is https://bugs.chromium.org/p/chromium/issues/detail?id=376039. We should at least have a design proposal and discussion within this quarter, even if implementation slips to next quarter.

[Rick Byers]

Thanks.  I added a couple notes to the bug.

I also did a little digging with httparchive to see if it's possible to search for service-worker specific uses there, but it looks like SW resources aren't captured.  I filed this issue to track that.

We do still support deprecation warning messages generated within a service worker context, right?  Could we at least get the deprecation warning added to M51 so we at least provide some warning to any developers that may be depending on this (and may occasionally look at the devtools console for their app)?

[Joshua Bell]

Since no-one else has commented, I've gone ahead and created a CL to add a deprecation warning for 51 (land deprecation, then immediately request a merge, then land the removal).

Sound good?

[Elliott Sprehn]

Yes, but I also think getting UMA and UseCounters fixed for both fast shutdown and workers is the P0 we keep ignoring here...

[Christian Biesinger]

They have been fixed for fast shutdown, no?
https://bugs.chromium.org/p/chromium/issues/detail?id=544971

Don't know about workers.

-Christian

[Elliott Sprehn]

Yay! Carry on then. :)

[Rick Byers]

That sounds good to me Josh.  I don't see any better option than just going with a deprecation warning for one milestone then removing and keeping a close eye out for any fall-out.  Worst case we'll learn something about the risks of changing service worker exposed APIs without the UMA coverage in place :-).

[Rick Byers]

So, LGTM2 to deprecate and remove according to that plan.

Chris, does your LGTM still stand after this debate?

[Chris Harrelson]

Yes, still LGTM.

[Dimitri Glazkov]

LGTM3

:DG<