Intent to Deprecate and Remove: FileReaderSync in service workers

[Marijn Kruisselbrink]

Primary eng (and PM) emails

m...@chromium.org

Summary

The Service Worker spec has always had the (non-normative) note that "any type of synchronous requests must not be initiated inside of a service worker", to avoid blocking the service worker (as blocking the service worker would block all network requests from controlled pages). However synchronous APIs such as FileReaderSync were still available in service workers. So we'd like to fix that by removing this API from service workers (see https://github.com/w3c/ServiceWorker/issues/735 and https://github.com/w3c/FileAPI/issues/16 for the very brief spec discussion about this).

Motivation

It's too easy to end up blocking all network requests for pages controlled by your service worker by calling blocking APIs from the service worker. So to avoid people shooting themselves in their feet, removing blocking APIs as much as possible as soon as possible makes sense.

Compatibility And Interoperability Risk

Currently both Firefox and Chrome expose FileReaderSync in service workers. There seemed to be agreement from firefox in the spec discussion that this should be fixed. So given that all browsers that support service workers also implement FileReaderSync there is of course a non-zero risk of breakage. Hopefully usage is low enough for this to not be too bad. To achieve this I'd like to land a deprecation warning in M58 (and backport to M57 if possible), and then go ahead with removing the feature in M59.

Alternative implementation suggestion for web developers

Developers could use the non-sync FileReader interface to read blobs/files in service workers.

Usage information from UseCounter

Unfortunately we don't have use counters in service workers yet. Support for use counters in service workers should land in M58 I believe (of course no guarantees there, as the code is still under review), so we should have at least some usage data by the time we get to removing the feature.

OWP launch tracking bug

https://crbug.com/688586

Entry on the feature dashboard

https://www.chromestatus.com/feature/5739144722513920

Requesting approval to remove too?

Yes. Admittedly we don't really have any data to base this decision on, but the hope is that not many service workers are currently using FileReaderSync. If usage turns out to be unexpectedly higher we'll of course have to revisit this decision.

[PhistucK]

You do not have any data (not even in non-service-worker contexts) about FileReaderSync, so I think you should at least add a use counter to contexts that are UseCountable (perhaps merge it to Chrome 57 in order to start getting some results).

Also, can you perhaps use regular UMA? Perhaps at a lower layer (in Chrome, say)? Or is the synchronous versus asynchronous handling defined in Blink alone?

I suspect that this API is almost never used in any context, so UMA numbers for usage of the API in general would be very helpful in order to make a more informed decision here.

☆PhistucK

--
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+unsubscribe@chromium.org.

[Marijn Kruisselbrink]

On Thu, Feb 9, 2017 at 2:49 PM, PhistucK <phis...@gmail.com> wrote:

You do not have any data (not even in non-service-worker contexts) about FileReaderSync, so I think you should at least add a use counter to contexts that are UseCountable (perhaps merge it to Chrome 57 in order to start getting some results).

 

The intersection of contexts that are use countable and contexts that support FileReaderSync are currently limited to just dedicated workers (in M58 shared workers just got added, and as mentioned, hopefully soon service workers support will land as well). I'm not sure how knowing how much FileReaderSync is used in dedicated workers will help us decide what to do about it in service workers? Of course for general knowledge having such a use counter might still be valuable.

Also, can you perhaps use regular UMA? Perhaps at a lower layer (in Chrome, say)? Or is the synchronous versus asynchronous handling defined in Blink alone?

I suspect that this API is almost never used in any context, so UMA numbers for usage of the API in general would be very helpful in order to make a more informed decision here.

I believe the sync/async handling is defined pretty much entirely in Blink. That of course doesn't mean that we couldn't use regular UMA. Regular UMA works just fine in Blink itself. So yes, I could definitely add a histogram that records the type of context whenever a FileReaderSync is created, or something similar. It won't really tell us how much usage is in relation to page loads, but would definitely give some better idea to how much this API is actually used. So yes, that's definitely something I'd like to do.

[Chris Harrelson]

LGTM to try this, as it's bad to let this API exist on service workers. Please land and try to backport what use counting you can (Phistuck's suggestion sounds plausible to me), and report back for M59 so we can make a final call.

--

[Philip Jägenstedt]

LGTM2 to measure, remove, and just check the numbers in time so that reverting is still possible.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Dimitri Glazkov]

LGTM3