- From: Jungkee Song <notifications@github.com>
- Date: Tue, 24 Mar 2015 19:20:12 -0700
- To: slightlyoff/ServiceWorker <ServiceWorker@noreply.github.com>
- Message-ID: <slightlyoff/ServiceWorker/issues/659/85787941@github.com>
> Is the current pattern to leave the registration with a null active state? When would it next pick up an update? (was there a discussion around this I missed?) Yes, it is, and the next update would be triggered by one of `navigator.serviceWorker.register()`, `registration.update()` from clients or Soft Update by the user agent. As you pointed, if it'd failed with the activation, there's a chance the storage state would have been broken. So I guess it's fair to make the service worker's state redundant to notify the activation failure. And as such the subsequent functional events should not be dispatched to this service worker until it gets recovered. > The current spec makes the SW the "active" worker immediately when activation begins, but it doesn't get any events until it becomes "activated". Right. So if we leave this an `activating` state, it won't serve any events until developer fix this. > Chrome additionally unregisters the registration if it has no workers, although that might be a implementation bug. As @jakearchibald said, "Unregistering is bad because you'll lose push registrations etc.". We're currently somewhat aggressively sweeping those registrations (having no worker) out during the Update/Install steps. I think it'd be still fine to unregister them when a network error (bad request or script fetch error) or a security error (path or MIME type error) occurs, but we can probably exclude the script execution error cases. --- Reply to this email directly or view it on GitHub: https://github.com/slightlyoff/ServiceWorker/issues/659#issuecomment-85787941
Received on Wednesday, 25 March 2015 02:20:42 UTC