Re: [w3c/ServiceWorker] Sort out settings object for service worker module scripts (#1013)

Hmm. I think it would be pretty bad to break the 1:1:1 correspondence. A lot of the platform assumes that.

Also, note what "fetch a worker script" uses the settings object for: it uses it to determine the referrer and such. So I don't think the service worker should be fetching itself, should it? It should be the settings object of the page itself that is doing `navigator.serviceWorker.register()`. In other words, I think you need a separate settings object for the fetching, and for the running of scripts. The fetching should be "outside", e.g. the initiating document. Whereas the  script running should be inside the service worker.

This might be different for future updates. But at least for the initial `navigator.serviceWorker.register()` it seems necessary.

> One tricky part is fetch a module worker script graph > .. > create a module script > ParseModule() requires a realm while service worker's Update doesn't create a realm. In my understanding, the only reason that the realm is passed is to set the created script's module record's [[Realm]] internal slot, right? If so, can I set/pass the environment settings object's Realm to undefined at this stage? And later override the value to the actual realm created in Run Service Worker?

Something like that might work, although we'd need to modify the spec to allow not passing in a realm (we can't just treat undefined as if it's a realm). But I wonder if after considering the above we can find some way to avoid this. I'd be very surprised if any implementation actually parses service worker scripts before creating an instance of the JS engine for the service worker scripts to run in. And the spec should ideally not do something so different from implementations.

-- 
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/1013#issuecomment-287208088