Client.postMessage() throwing for unloaded client is problematic

[wanderview]

Currently Client.postMessage() says:

2. Let destination be the ServiceWorkerContainer object whose
service worker client is the context object’s service worker client,
or null if no match is found.

3. If destination is null, throw an "InvalidStateError" DOMException.

This is problematic for a few reasons:

1. Most postMessage() implementations don't throw. They just silently consume the message if the other end is no longer listening. For example Worker.postMessage() and MessageChannel, etc.
2. The lookup of the destination is presented as synchronous in the spec, but it must be async in any cross-process browser implementation.

If we wanted we could change postMessage() to return a promise, but its probably better to just silently eat the message.

I'm filing this issue in regards to web-platform-tests/wpt#10153

[wanderview]

cc @jungkees

[jungkees]

I see. port.postMessage just returns when the target is unavailable. (Step 6 of https://html.spec.whatwg.org/#dom-messageport-postmessage.) I'm not sure though we had had any specific intent to make Client.postMessage throw in the current text.

@jakearchibald, do you recall anything about it?

From web-platform-tests/wpt#10153 (comment),

@jungkees Also, how is the implementation capable of synchronously throwing here? The client and its ServiceWorkerContainer may be in another process.

When @mattto approved #1274, I thought we could maintain a data structure in the browser process that tracks the clients.

/cc @aliams @cdumez

[mfalken]

I didn't realize postMessage usually doesn't throw. Sounds like we should just drop the message silently then.

[jungkees]

drop the message silently

Would this be trying to get the destination and returning if the target doesn't exist? Or just queuing a task for the event and the task failing to find a target in the content process?

I think port.postMessage step 6 is doing the former based on the state it keeping in the sender's process (not crossing the process boundary at the time of the call). Then, it won't cover the case where the target port has been nullified in the target process.

Do you expect we have a similar behavior for client.postMessage?

[mfalken]

It sounds like postMessage should just be best-effort and if the message couldn't be delivered, regardless of the reason, it just fails silently.

[domenic]

I don't think this is relevant to the current bug thread, but I wanted to point out that that is not quite the general principle these days. In particular messages that cannot be delivered because of deserialization errors (such as crossing process boundaries while passing a SharedArrayBuffer) are currently specced to generate a messageerror event at the destination. (We talked a bit about signaling back to the source, but that's tricky, and the whole discussion was light on use cases, so it was deferred.)

Just something to remember when talking about the model of how postMessage deals with errors.

[wanderview]

When @mattto approved #1274, I thought we could maintain a data structure in the browser process that tracks the clients.

Sure, the list is maintained in the browser process, but accessing that list from the renderer process is going to be async. Unless we want to block or spin the event loop while we consult cross-process state we can't synchronously throw here.

IMO anyway.

[jungkees]

@domenic, thanks for the information. Good to be aware of for future discussion.

Sure, the list is maintained in the browser process, but accessing that list from the renderer process is going to be async.

Ah.. right. This call starts from the renderer. I was confused myself we were on the browser process at the beginning.

I'll make another PR to address this issue and close the PR in WPT.

I'm thinking of getting the associated service worker client and returning if it doesn't exist, which would be analogous to https://cs.chromium.org/chromium/src/content/browser/service_worker/service_worker_version.cc?type=cs&q=ServiceWorkerVersion::PostMessageToClient&l=1155.