Bug 677638 gave us MessagePorts and bug 516752 is giving us e10s. Bug 914451 wants both of these, so wants a way to transfer a message port from the chrome process to a content process via nsIFrameMessageManager. A complication here is that sendAsyncMessage etc have already "stolen" the 3rd arg for CPOW objects - ideally it could morph into something like "cpowsAndTransferables" so CPOWs *and* other transferrable objects could be specified. Seeing sendAsyncMessage isn't a web api, it would also be OK for the port to be passed in msg.data, although it would need special casing as a MessagePort can't be copied, only transferred. My testing shows the port object actually *can* be specified in the message data, but the receiving end doesn't actually see a MessagePort, just an [object Object] that doesn't work as a port - but that might just be bug 912456, which I expect might stop even that much working.
Yeah, ideally we could figure out how to marshal it along with msg.data. Is it only going to be used with sendAsyncMessage? If so, you could also consider adding a sendMessagePort.
(In reply to David Anderson [:dvander] (inactive, r?/f?/ni? to ping) from comment #1) > Yeah, ideally we could figure out how to marshal it along with msg.data. Is > it only going to be used with sendAsyncMessage? If so, you could also > consider adding a sendMessagePort. For our use case we would rather have it as separate argument on the `sendAsyncMessage` because port may be sent with an associated message. Having different method will require coordination of the message and associated port manually.
Maybe we can get rid of all these troubles by adding a `sendAsyncMessageEx(name, data, transferables, cpows)` method.
Mass tracking-e10s flag change. Filter bugmail on "2be0fcce-e36a-4e2c-aa80-0e3d33eb5406".
tracking-e10s: --- → +
You need to log in before you can comment on or make changes to this bug.