Intent to Implement and Ship: Do not resurrect uninstalled service workers

111 views
Skip to first unread message

Yannic Bonenberger

unread,
Sep 9, 2019, 8:47:49 AM9/9/19
to blink-dev

Contact emails

yannic.bo...@gmail.com


Explainer

https://github.com/w3c/ServiceWorker/issues/1204


Spec

https://w3c.github.io/ServiceWorker/


TAG review

Skipped. This does not expose a new API.


Summary

Previously, service workers were resurrected when they were updated or when the same script was registered while the service worker was still alive. Now, registering a service worker will always create a new instance, regardless of whether there already is a running instance or not. This spec change was intended to address the confusion that a service worker could become active again with no corresponding activate event.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.


Risks

Interoperability and Compatibility

Developers were not aware that service workers could be resurrected, and those that encountered it expected it to be a bug. The consensus at TPAC 2018 was to remove resurrection from the spec.


Edge: No public signals

Firefox: Shipped

Safari: No public signals

Web developers: No signals



Is this feature fully tested by web-platform-tests?

Yes.

https://github.com/web-platform-tests/wpt/pull/17139

https://github.com/web-platform-tests/wpt/pull/17203


Tracking bug

https://crbug.com/971571


Entry on the feature dashboard

https://chromestatus.com/feature/5646687634718720


Requesting approval to ship?

Yes.


Daniel Bratell

unread,
Sep 9, 2019, 11:21:35 AM9/9/19
to blink-dev, Yannic Bonenberger
LGTM1

/Daniel
--
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5c769e89-a2fb-43a3-9750-e80bbcc756b7%40chromium.org.



--
/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

Yoav Weiss

unread,
Sep 12, 2019, 12:05:39 PM9/12/19
to Yannic Bonenberger, blink-dev
On Mon, Sep 9, 2019 at 2:47 PM Yannic Bonenberger <con...@yannic-bonenberger.com> wrote:

Contact emails

yannic.bo...@gmail.com


Explainer

https://github.com/w3c/ServiceWorker/issues/1204


Spec

https://w3c.github.io/ServiceWorker/


TAG review

Skipped. This does not expose a new API.


Summary

Previously, service workers were resurrected when they were updated or when the same script was registered while the service worker was still alive. Now, registering a service worker will always create a new instance, regardless of whether there already is a running instance or not. This spec change was intended to address the confusion that a service worker could become active again with no corresponding activate event.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.


Risks

Interoperability and Compatibility

Developers were not aware that service workers could be resurrected, and those that encountered it expected it to be a bug. The consensus at TPAC 2018 was to remove resurrection from the spec.


Does that mean that it wasn't web exposed? Or it was and it's just that most folks weren't aware of it?
What are the chances of sites relying on this? (intentionally or unintentionally)
 

Chris Palmer

unread,
Sep 13, 2019, 1:57:02 PM9/13/19
to blink-dev, con...@yannic-bonenberger.com
Do we need to update the Service Worker Security FAQ?
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

Ben Kelly

unread,
Sep 14, 2019, 4:09:35 AM9/14/19
to Yoav Weiss, Yannic Bonenberger, blink-dev
On Fri, Sep 13, 2019 at 1:05 AM Yoav Weiss <yo...@yoav.ws> wrote:
On Mon, Sep 9, 2019 at 2:47 PM Yannic Bonenberger <con...@yannic-bonenberger.com> wrote:

Risks

Interoperability and Compatibility

Developers were not aware that service workers could be resurrected, and those that encountered it expected it to be a bug. The consensus at TPAC 2018 was to remove resurrection from the spec.


Does that mean that it wasn't web exposed? Or it was and it's just that most folks weren't aware of it?
What are the chances of sites relying on this? (intentionally or unintentionally)

In our experience web developers do not expect or want the previous behavior of resurrecting registrations.  Generally they are much more interested in ensuring registrations go away when they implement a kill switch for service workers, etc.

Also, the new behavior still results in a service worker being registered.  The only difference is that you will get a new set of install/activate events.  The typical install/activate will simply redownload cached resources and should have no problem running again.

The risk of sites being dependent on the old behavior and breaking with the new behavior seems low.

We could try to add use counters for resurrections, but we would not have a way to tell if the install/activate event firing would cause a problem or not.

Ben Kelly

unread,
Sep 14, 2019, 4:13:07 AM9/14/19
to Chris Palmer, blink-dev, Yannic Bonenberger
On Sat, Sep 14, 2019 at 2:57 AM 'Chris Palmer' via blink-dev <blin...@chromium.org> wrote:
Do we need to update the Service Worker Security FAQ?

I skimmed the FAQ and I don't think anything relevant changes with this intent. 
 
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/aaec9fce-10a7-4fe4-ba24-6e9ae9687f71%40chromium.org.

Chris Palmer

unread,
Sep 16, 2019, 1:39:16 PM9/16/19
to Ben Kelly, blink-dev, Yannic Bonenberger
So there was no issue with kill-switches not working, or anything like that?

Yannic Bonenberger

unread,
Sep 19, 2019, 2:46:57 PM9/19/19
to blink-dev, wande...@chromium.org, con...@yannic-bonenberger.com
When we talk about kill-switches, we usually mean kill-switches sites implement in their service workers to ensure the worker doesn't cause any damage to the site in the event of bad deployments. They'll still work with the change. The difference is that sites are guaranteed to get a new version when register() is called after unregister() (before, the old service worker may get resurrected). If you think about it, that's probably an improvement!

For the Security story of Chrome, this makes absolutely no difference. Just like before, we'll kill the service worker when it hasn't received an external event for some time (IIRC, that limit is 5min right now). Since service workers can't register other service workers, there's no way of circumventing that limit by unregistering and immediately registering again.

Chris Palmer

unread,
Sep 19, 2019, 2:49:44 PM9/19/19
to Yannic Bonenberger, blink-dev, Ben Kelly
OK, sounds good. Thank you!

You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/r176Lvgxfys/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/863a8451-db70-4526-bcf4-f128b1b40bb2%40chromium.org.

Chris Harrelson

unread,
Sep 19, 2019, 3:13:17 PM9/19/19
to Chris Palmer, Yannic Bonenberger, blink-dev, Ben Kelly
LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOuvq227M0LYDC87x2Mv%2Bxwq41%2BmLtOMN4rboQ%2B%3DvJWc%3DgBstQ%40mail.gmail.com.

Yannic Bonenberger

unread,
Sep 19, 2019, 3:14:51 PM9/19/19
to blink-dev, con...@yannic-bonenberger.com


On Thursday, September 12, 2019 at 6:05:39 PM UTC+2, Yoav Weiss wrote:


On Mon, Sep 9, 2019 at 2:47 PM Yannic Bonenberger <con...@yannic-bonenberger.com> wrote:

Contact emails

yannic.bo...@gmail.com


Explainer

https://github.com/w3c/ServiceWorker/issues/1204


Spec

https://w3c.github.io/ServiceWorker/


TAG review

Skipped. This does not expose a new API.


Summary

Previously, service workers were resurrected when they were updated or when the same script was registered while the service worker was still alive. Now, registering a service worker will always create a new instance, regardless of whether there already is a running instance or not. This spec change was intended to address the confusion that a service worker could become active again with no corresponding activate event.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.


Risks

Interoperability and Compatibility

Developers were not aware that service workers could be resurrected, and those that encountered it expected it to be a bug. The consensus at TPAC 2018 was to remove resurrection from the spec.


Does that mean that it wasn't web exposed? Or it was and it's just that most folks weren't aware of it?
What are the chances of sites relying on this? (intentionally or unintentionally)

The feature was observable. It's just that most folks aren't aware of it.
As Ben said, we could add a use counter to detect if service workers are resurrected, but we have absolutely no way to tell whether registering a new worker instead would cause any issues. 
Given that Firefox already shipped this, and we're not aware that it caused any breakage, the chances of sites relying on it are very low.
 
 

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

Ben Kelly

unread,
Sep 19, 2019, 9:26:54 PM9/19/19
to Yannic Bonenberger, blink-dev
On Fri, Sep 20, 2019 at 4:14 AM Yannic Bonenberger <con...@yannic-bonenberger.com> wrote:
On Thursday, September 12, 2019 at 6:05:39 PM UTC+2, Yoav Weiss wrote:
On Mon, Sep 9, 2019 at 2:47 PM Yannic Bonenberger <con...@yannic-bonenberger.com> wrote:

Risks

Interoperability and Compatibility

Developers were not aware that service workers could be resurrected, and those that encountered it expected it to be a bug. The consensus at TPAC 2018 was to remove resurrection from the spec.


Does that mean that it wasn't web exposed? Or it was and it's just that most folks weren't aware of it?
What are the chances of sites relying on this? (intentionally or unintentionally)

The feature was observable. It's just that most folks aren't aware of it.
As Ben said, we could add a use counter to detect if service workers are resurrected, but we have absolutely no way to tell whether registering a new worker instead would cause any issues. 
Given that Firefox already shipped this, and we're not aware that it caused any breakage, the chances of sites relying on it are very low.

I agree the risk is low (as previously stated), but just want to point out that I don't think the firefox implementation has hit their stable channel yet.  That is scheduled for FF70 release on October 22.  So it's probably premature to rely on that as a strong compat signal.
 
 
 

--
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 blin...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5c769e89-a2fb-43a3-9750-e80bbcc756b7%40chromium.org.

--
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/016beb82-5a00-4fbd-9ca6-5440d56c975a%40chromium.org.

Philip Jägenstedt

unread,
Sep 20, 2019, 7:18:51 AM9/20/19
to Ben Kelly, Yannic Bonenberger, blink-dev
Reply all
Reply to author
Forward
0 new messages