Re: [w3c/ServiceWorker] Use right value for Resolve Job Promise (#1054)

It kind of feels extremely pedantic (and specs in general seem to do a terribly job at specifying what Realm objects are created in), but this doesn't quite seem correct yet (other than "the value that corresponds to value" not seeming very well defined). In particular at the places where _Resolve Job Promise_ is called we currently call it with a `ServiceWorkerRegistration` instance, without specifying in which Realm that instance is created (and all of that generally is done from code that is run _in parallel_, so there isn't really an implied task/real/context either). 

Maybe the right fix would be to pass the _service worker registration_ itself, rather than a javasript object associated with it to _Resolve Job Promise_, and then have the tasks that are queued by _Resolve Job Promise_ create (or lookup? I'm not sure from reading the current spec if we're supposed to always return the same instance for the same registration in the same realm, or if a different instance can be returned sometimes) the correct instance to resolve the promise with.

Not sure how we'd then deal with the one job type that doesn't resolve with a registration, but instead with a boolean. And again all of this feels very pedantic and doesn't seem to be something that most specs get right either (probably because actually getting it right is so tricky/complicated).

Also to be truly pedantic, _Reject Job Promise_ should probably make it explicit that all the different promises get rejected with different instances of the same type of exception. As currently spec'ed the following test would pass, which I don't think is desired:

```js
let p1 = navigator.serviceWorker.register("http://example.com/foo.js");
let p2 = navigator.serviceWorker.register("http://example.com/foo.js");

p1.catch(e => e.custom = "bla");
p2.catch(e => assert_equals(e.custom, "bla"));
```

Maybe the easiest fix is to completely get rid of the _Resolve Job Promise_ and _Reject Job Promise_ algorithms, but that of course would make all the algorithms currently using them more complicated, which would also suck.

-- 
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/pull/1054#issuecomment-272274689