Contact emails
jka...@chromium.org, icle...@chromium.org, owe...@chromium.org
Spec
Link to spec and pending tag review.
Summary
A ServiceWorker onsync event that can be registered for from a main-frame document or service worker with a main-frame client. Once registered, the onsync event will fire when next online (even after the page or browser has closed). The event doesn’t finish until either five minutes have passed, the event completes without a waitUntil, or the waitUntil rejects/resolves. If the event fails, the browser will retry (exponential backoff) up to a total of five attempts.
Motivation
Web Applications often run in environments with unreliable networks (e.g., mobile phones) and unknown lifetimes (the browser might be killed or the user might navigate away). This makes it difficult to synchronize client data from web apps (such as photo uploads, document changes, or composed emails) with servers. If the browser closes or the user navigates away before synchronization can complete, the app must wait until the user revisits the page to try again. This specification provides a new onsync service worker event which can fire in the background so that synchronization attempts can continue despite adverse conditions when initially requested. This API is intended to reduce the time between content creation and content synchronization with the server.
Link to “Intent to Implement” blink-dev discussion
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/iaAyTxWmx7o/SBDhV0UWa-sJ
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
The API functions on all platforms (that is, you can register for a sync and once you’re online it will fire). However, only on Android (non-WebView) will it fire after the browser has closed. In future releases, desktop versions will extend the lifetime of the browser process with Background mode for the duration of the sync registration.
Demo link
https://wicg.github.io/BackgroundSync/demo/
Debuggability
No DevTools support as yet, though it would be desirable.
Interoperability and Compatibility Risk
The spec was collaboratively designed with Chrome and Mozilla developers and Mozilla has expressed interest in developing this. There is ongoing privacy discussion for APIs that allow background processing such as sendBeacon and Background Sync which may result in the addition of permissions or notifications in future releases.
OWP launch tracking bug
https://code.google.com/p/chromium/issues/detail?id=449443
Entry on the feature dashboard
https://www.chromestatus.com/features/6170807885627392I think it's a good question, but broader than just this feature. Chrome-wide we have an issue that users can't tell how much bandwidth any origin is using which is a problem especially for emerging markets. For example, users can't know if that news article they just read took 3MB (read: cost $1) loading an ad etc.
I believe there is a plan to instrument and expose network usage which will help a lot, including in this case. When that is in place I think I expect it will allow users to have some control over limiting origins bandwidth usage which this could be part of.
The spec seems like it could use some work, for example it has a "tag" concept but never explains its purpose beyond a single example that uses it.
It'd be nice if the spec had some more descriptions of what the various parts of the API were for, and how they're expected to be used. For example why can I register tags but not unregister them? :)
--
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.
I've looked through the spec and the demo and think this all looks very nice, just a few questions.
https://wicg.github.io/BackgroundSync/demo/ works on a fresh install of Chrome Dev on Windows, but not on Linux, where I get the error "Failed to execute 'register' on 'SyncManager': parameter 1 ('options') is not an object." This error looks like it happens before any of the new code would even run, but have you seen it before and can you fix it?
Also, the spec says Exposed=(Window,Worker) but the implementation uses Exposed=(Window,ServiceWorker). Is this intentional, or should the API be exposed in other kinds of workers as well?
The privacy issues are interesting, but I don't have anything to add. I assume that has this gone through internal security+privacy review or that it will before shipping?
On Wed, Dec 9, 2015 at 9:05 AM, Philip Jägenstedt <phi...@opera.com> wrote:I've looked through the spec and the demo and think this all looks very nice, just a few questions.
https://wicg.github.io/BackgroundSync/demo/ works on a fresh install of Chrome Dev on Windows, but not on Linux, where I get the error "Failed to execute 'register' on 'SyncManager': parameter 1 ('options') is not an object." This error looks like it happens before any of the new code would even run, but have you seen it before and can you fix it?That shouldn't happen; if it does it's certainly a (launch-blocking) bug. I landed the API change right before Chrome 48 beta was released, but it's possible that the patch didn't make it into the Linux build of Chrome Dev Channel. Can you try it out on Canary?
Also, the spec says Exposed=(Window,Worker) but the implementation uses Exposed=(Window,ServiceWorker). Is this intentional, or should the API be exposed in other kinds of workers as well?Ideally, yes, it should be available to Web Workers, as well as service workers. crbug.com/532989 is tracking this, but it is currently blocked on crbug.com/371690. (ServiceWorker *itself* isn't exposed to workers yet in Chrome)
The privacy issues are interesting, but I don't have anything to add. I assume that has this gone through internal security+privacy review or that it will before shipping?Yes. Privacy review (crbug.com/542110) is passed, and I think that egm's comment (https://code.google.com/p/chromium/issues/detail?id=539985#c18) means that security review has, as well. The launch would certainly be blocked on both of those reviews, if they were still pending.
--