Re: [w3c/ServiceWorker] consider allowing a non-scope identifier for registrations (#1512)

Sorry, I did not address it in my previous comment.  I propose:

5. Changing the scope of a registration would still need to pass the path-restriction/ServiceWorkerAllowed check just like if registered from scratch.  (I assume we do this when changing the script URL on a registration today?)
6. By default the new service worker will not activate if there are existing controlled clients.
7. skipWaiting() will cause the new service worker to activate and any existing controlled clients not covered by the new scope become uncontrolled via a controlchange event.
8. The registration.scope attribute reflects the scope associated with the oldest worker, so the scope attribute does not change until the new service worker activates.

The main ugliness here is that the scope is now associated with a version of the service worker and not the registration as a whole.  Its a worse form of the updateViaCache change on the registration previously.

Should I expose a ServiceWorker.scope to reflect the scope of each version?  I'm not sure it would be used in the algorithm, but it might help folks understand that it can change.  Not sure on that one.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1512#issuecomment-666693719