Primary eng (and PM) emails
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).
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
Entry on the feature dashboard
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.
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 email@example.com.
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.