Expose transferList on MessageEvent

[surma]

I sometimes find myself using a Man-in-the-middle pattern with MessageChannel:

          +------------------------------+
          |                              |
portA1 =======> portA2   f()   portB1 =======> portB2
          |                              |
          +------------------------------+

Any message that gets sen via portA1 can eventually be received at portB2, but the function f has the opportunity to mangle, log or otherwise manipulate the message payload before it gets forwarded.

If the original message is sent with a transferList, the function has no way of accessing that transferList and forwarding the message with the same transfer behavior.

I think it would be good if the transferList could be exposed on MessageEvent.

Talking to @domenic OOB, this could be useful for the discussion around transferable values in the context of transferable Streams.

[domenic]

This seems like a clear use case, and from the spec side, is quite easy to add. Plus, it just makes sense; we're currently throwing away the useful information of what got transferred, when we could expose it.

Right now StructuredDeserializeWithTransfer returns a record with a [[TransferredValues]] field, which we grab the MessagePort objects out of (to populate the event's ports property) but ignore the rest of. This would consist of just adding a transferred event property or similar and putting all the values there, as a FrozenArray<object>.

I don't know if it's that straightforward in implementations, but hopefully not too bad.

Are there any implementers who would be interested in weighing in on this? Going to guess @nhiroki, @rniwa, and @smaug---- could point us in the right direction? /cc @ricea for the streams connection, although I think that's a ways out at this point.

[smaug----]

Initial thought is that this is reasonable.

This wouldn't be trivial to implement in Gecko, but shouldn't be too bad, I think.
@bakulf

[annevk]

cc @chihweitung

[bakulf]

It's not hard to do this in gecko. +1.

[surma]

Circling back to this: Is it appropriate to PR in a spec change at this point?

[domenic]

PRs are always welcome; they wouldn't be merged until we have multi-implementer interest, but they can definitely help move things along.

[annevk]

If there's buy-in from Chrome, you got what you need to start doing that (and writing tests).