This bug is not currently tracked.
Attempting to use PBrowserOrId as a parameter on a function within a protocol between the content process and the socket process results in assertions here:
The error is ultimately caused by a failure here:
The ids that are used on |Lookup| (and the related |Register|, |Unregister|, etc) have a lower-order bit that encodes whether the Protocol is a "parent" or not:
All ids that are registered on the socket process do not have this bit set, because the socket process is not considered a parent process. However, the id passed for PBrowser does have the parent bit set (presumably because the socket process is where the "parent" side of the protocol resides), so the lookup fails.
Actor references are local to their top-level protocol (== IPC channel) and can't be sent over unrelated actors. This applies in general (i.e., even for two toplevels between the same pair of processes and/or of the same type), but in this case it's not even the right process — the deserialization function can't return a PBrowserParent* because the intended PBrowserParent is in a different address space.
What is the expected behavior here? Specifically, what is the socket process expecting to do with a TabParent object?
It is expected to use it to open a PWebrtcProxyChannel:
The WebrtcProxyChannelParent constructor seems to use only the TabParent's implementation of nsIAuthPromptProvider, which has something to do with bug 1203503. The socket process is going to have to talk to the parent process directly to handle that, and I don't think there's anything in IPC as it currently exists that can help with identifying the tab.
My understanding is that tabs/windows/frames already have IDs that are unique within the browser instance, which could be sent from a content process to the socket process and forwarded to the parent process, but I don't know how hard it is to get back to a TabParent from that. Also, the parent and socket processes would have to compare OtherPid() values to prevent impersonating a different content process.
Nika, I think you had some ideas about how to identify the TabParent in a way that will work with process-separated networking?
Well, the reason why the name of the field is PBrowserOrId was because we needed to pass around these identifiers in processes which don't have the PBrowser (namely for the old out-of-process nested mozbrowser tags).
I think the best option here is to explicitly only pass TabId around to these places.