Add onclose event to MessagePort

[isonmad]

There's currently no reliable way to detect when a MessagePort becomes disentangled, whether due to purposefully calling .close(), or the tab being unexpectedly killed.

An onclose event was proposed and discussed several years ago, but it looks like the discussion petered out after that.

Any hope of reviving it?

[annevk]

It doesn't really work with the MessageChannel model as discussed in that email. Do you have a specific proposal that doesn't expose GC?

[isonmad]

Reading over the thread and the spec again, that particular email's claim that there's ambiguity about what a port's 'owner' is is actually wrong. The spec does define what settings object owns the port, and sharing a reference doesn't change it. The pass-port-around case is already basically broken, it looks like.

What about an event that fires:

• When .close() is called explicitly
• If the port's owner is a WorkerGlobalScope, when Worker.terminate is called
• If the port's owner is a WorkerGlobalScope, when the worker's last Document is unloaded
• If the port's owner is a Window, when the page is unloaded

[domenic]

I'll dupe https://www.w3.org/Bugs/Public/show_bug.cgi?id=28813 against this.

[annevk]

@isonmad the problem with that is that rather than exposing GC, you end up creating a memory leak by keeping the objects alive for the duration of the global. I think service workers ended up doing this without much thought about it.

[isonmad]

That was in the thread too, and it turned out there was already a leak of MessagePorts, at least in Chrome in 2013, and the spec language was written around that fact that devs should be careful regardless and not depend on GC.

But is there a technical reason the MessagePort object itself actually has to be kept alive in its entirety in implementations of onclose? It seems like there just needs to be an event in Context A, where the onclose handler was set, that fires whenever the other end of the port, Context B, goes away. Which context 'Context B' refers to can change within the lifetime of the MessagePort as it's passed around, but at the point where the MessagePort in B has no more references to it, and the leak might occur, can't it just be GC'd and replaced with a simpler, equivalent internal event listener where A just subscribes to and listens for B's demise? There must be some centralized tracking of processes/contexts, right.

[nornagon]

I'd like to see this revived now that WeakRef is available, and in light of similar APIs which do offer the 'close' event. It seems like this event would be the only way to know when the other end of the channel goes away—especially for unexpected failures such as crashes or OOMs.

(My interest specifically comes from using MessagePorts in Electron as a general-purpose IPC tool)

[Gaubee]

I use LockManager to shim web-worker onclose.

/// worker
const lockReqId = 'process-live-'+Date.now()+Math.random();
navigator.locks.request(lockReqId,()=>new Promise(()=>{}));
postMessage(lockReqId);

/// master
worker.addEventListener('message', me=>{
  if(typeof me.data==='string' && me.data.startsWith("process-live-")){
    navigator.locks.request(me.data,()=>{
      worker.dispatchEvent(new CloseEvent('close'))
    })
  }
});

I use LockManager to shim web-worker onclose.

[asutherland]

I'd like to revisit this; in Firefox we're implementing Web Locks and it seems like absent a MessagePort close event or a newly introduced disconnect event on SharedWorkerGlobalScope, the above comment's WebLocks shim will end up becoming a necessity.

I too re-read the original mailing list thread from the start that was linked to in the top comment in this issue and it seemed like the primary discussion points were:

• GC observability was a concern, with a proposal being "Tying it to something else (like when the owning document/worker is discarded, or the associated process shuts down/crashes) is more deterministic."
• To sidestep the GC issue, Firefox engineers proposed a "channeldropped" event to capture the exceptional situation where a process is terminated/crashed and so there's no opportunity for the global to postMessage a notification that it's going away. Event listeners would count as a strong reference that would inhibit GC of the MesagePort as long as the listener exist because the potential for a "channeldropped" notification would always exist.
• bfcache was a concern.

With Web Locks (which is moving to WebApps WG) exposing same-storage-key agent termination and ServiceWorkers exposing same-storage-key client enumeration via matchAll, there already exist same-origin mechanisms to surface lifecycle.

I think the main risk with the "close" event proposal here is that it could potentially expose cross-origin life-cycles in an adversarial manner if not constrained. Specifically, if WindowProxy.postMessage(..., "*", ...) is used to transfer a MessagePort into a different origin, would this allow the sender of the message to monitor when that agent terminates with no opt-in by the recipient agent? Presumably this could be addressed by requiring the (cross-origin) recipient to take some affirmative action indicating it wants to use the MessagePort by adding an event listener on it or invoking postMessage on it or something like that.