Re: How Does Render-to-Render IPC Works?

[Daniel Cheng]

If we needed to add new IPCs, one straightforward way is to add a method to LocalFrameHost; the browser process can trivially walk up the ancestor chain to send IPCs.

That being said, there's also FrameReplicationState and FrameOwnerProperties: depending on what you're trying to do, it might also make more sense to integrate the state you're trying to pass to one of those structs.

Can you give a bit more background on what you're trying to accomplish?

Daniel

On Thu, 16 Feb 2023 at 08:55, Hao Liu <hao...@chromium.org> wrote:

Hi,

I have a problem.

For a frame, I want to send some data to all its ancestor frames hosted in other render processes.  

One way is render-browser-render.

The other is render-to-render IPC.

But I'm trying to understand how oner render process can keep track of the render processes hosting its ancestors. 

I suppose when a frame is added and hosted in another render process, it need to inform its ancestors and its descendants. This seems to be very complicated if not unmanageable. 

I'm wondering if if there is a simple way to do this?

I didn't find any documentation on this. 

Does anyone know about this? Thanks

--
You received this message because you are subscribed to the Google Groups "chromium-mojo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-moj...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-mojo/82255a48-11da-40c3-89d0-add058410dc1n%40chromium.org.

[Charlie Reis]

I chimed in on this here as well: https://groups.google.com/a/chromium.org/g/chromium-dev/c/9w6wf6sQ3IA/m/osfXZi3RAQAJ

Daniel, do you know if we generally support renderer-to-renderer IPCs?  I'm hoping we still usually encourage/require going through the browser process for validation (as we do for postMessage), to limit the attack surface between renderers.

Charlie

[Dave Tapuska]

I don't believe we have renderer-to-renderer IPCs. We do have renderer->gpu process and possibly renderer -> network service. But the renderer->renderer as described above all go via the browser from my understanding. 

dave.

[Daniel Cheng]

I don't think we have IPCs that are directly bootstrapped to be renderer-to-renderer. But as mek@ alluded to in the other thread, there are various ways where a renderer might end up talking to another renderer directly (e.g. MessagePort or a URLLoader that is ultimately interacting with a service worker).

I still think it would be helpful to understand more of the background here in order to provide a better recommendation for what to do.

Daniel

[Daniel Cheng]

Can you give some background about what the goal here is? That would help guide recommendations (for example, there might be data we're already syncing between frames that this can piggyback on top of).

Daniel

On Fri, 17 Feb 2023 at 07:40, Hao Liu <hao...@chromium.org> wrote:

Thanks all for the answers!

I was leaning toward the render-browser-render model as it seems to be as pattern we use while render-to-render requires some sort of keeping track of frames added/removed. 

but the idea of render-to-render saves 1 ipc so I wanted to find out its feasibility.

I think I'll just go with the render-browser-render model as Daniel suggested.