unclear how Client.postMessage looks up its destination

[isonmad]

1. Let |destination| be the {{ServiceWorkerContainer}} object whose [=ServiceWorkerContainer/service worker client=] is the context object's [=Client/service worker client=].
2. If |destination| is null, throw an "{{InvalidStateError}}" exception.

It sort of sounds like looking through the set of all ServiceWorkerContainers that possibly exist, and it's only implied that it sets destination to null if it didn't find any. Is it possible to make the mapping from service worker client -> ServiceWorkerContainer more explicit?

It's not clear in what cases it wouldn't find one.

[jungkees]

Is it possible to make the mapping from service worker client -> ServiceWorkerContainer more explicit?

Please see the definition of the association between a ServiceWorkerContainer and a service worker client: https://w3c.github.io/ServiceWorker/#serviceworkercontainer-service-worker-client. client.postMessage() basically tries to reference the ServiceWorkerContainer object that is associated with the service worker client in that sense. Informally speaking, that's the captured client's document's ServiceWorkerContainer object.

It's not clear in what cases it wouldn't find one.

Client objects retrieved from client APIs are snapshots. So, the states are captured in the Client creation time: https://w3c.github.io/ServiceWorker/#create-client. So, by the time the steps of the postMessage() is running, the client may already have been closed. The null-check is a guard against this occasion.

Note that by introducing the "reserved client concept" lately, the message queuing mechanism for client.postMessage() needs changes since it can be possible that a ServiceWorkerContainer object hasn't been created by the time 'postMessage()` is run. The issue filed in #1035.

[isonmad]

I did read that definition, it makes for an explicit ServiceWorkerContainer -> service worker client mapping, and while it describes a way to do the inverse mapping as part of the definition, that inverse isn't actually given its own definition for use elsewhere. Whereas something like the 1-to-1-to-1 relation for Realm/global/settings object defines all six mappings between the associated objects explicitly. As is, it's like saying "let x be the JavaScript realm whose [[GlobalObject]] field is window" instead of the more straightforward "window's Realm".

The null-check still makes no sense, because it didn't say e.g. "let destination be the [[SWContainer]] internal slot of the service worker client", which could be either a ServiceWorkerContainer or null, with a step elsewhere in the spec that sets it to null when the client closes. It uses much more convoluted and indirect wording, and you have to infer that it's supposed to set destination to null if the wording as-is, taken literally, is effectively impossible, because there is no Container that fits that description anymore.

[jungkees]

it makes for an explicit ServiceWorkerContainer -> service worker client mapping

What spec says is not a mapping between a ServiceWorkerContainer and a service worker client. ServiceWorkerContainer's associated service worker client explicitly defines a reference to the service worker client of the Window/Navigator where ServiceWorkerClient is tied. I don't see a problem in this definition.

The null-check still makes no sense

Agreed. The destination should be initialized to null and should remain null if it doesn't get a target object. I'll address that point.

[wanderview]

See #1291. I don't think browsers can reasonably look up the destination synchronously. Cross-thread and cross-process issues require the lookup to be asynchronous.