Mojo services racy between renderer and browser processes?

[Ben Wagner]

Hi team,

I'm following up on an issue I found when the browser process makes a Mojo connection to a service in the renderer process. The behavior is surprising to me, but possibly working as intended.

The TLDR is:

1. An object stored in RenderFrameHostImpl::document_associated_data_ uses RenderFrameHost::GetRemoteInterfaces to create a Mojo pipe to the renderer process.

2. Before the pipe is bound, the page gets reloaded, which creates a new LocalDOMWindow in the renderer.

3. The pending receiver from step 1 gets bound to a new implementation of the Mojo interface, which is a Supplement<LocalDOMWindow>.

The result is that an object associated with the old document on the browser side is connected to a service for the new document on the renderer side.

You can find more info about which specific objects/interfaces are involved and why this results in a bug at https://bugs.chromium.org/p/chromium/issues/detail?id=1285178#c13. 

This only seems to happen for reloads and same-origin navigation. (It was easy to manually repro the bug with a same-origin navigation but the same test with a cross-origin navigation never triggered the bug.) 

I tried changing to use associated interfaces (so instead of GetRemoteInterfaces, call GetRemoteAssociatedInterfaces), but that didn't fix the bug.

My questions are:

1. Is there something that prevents this bug from happening on a cross-origin navigation? I wasn't able to convince myself by looking at the code. It seems pretty bad if we can have a Mojo pipe where the endpoints believe they're dealing with different origins.

2. Could other services be affected by this surprising behavior? E.g. a call to RemoveHighlightsInFrame ends up being handled by a TextFragmentHandler for a different frame?

Thanks!

Ben

[Reilly Grant]

Interesting. I think most of the work that's been done in this space is concerned about the opposite problem, making sure connections from a particular document get associated with objects in the right RenderFrameHostImpl::document_associated_data_. I don't know if as much work has gone into making sure connections in the browser to renderer direction are similarly well-organized.

My initial thought for how to fix this is to generally avoid using RenderFrameHost::GetRemoteInterfaces and always have the renderer make the initial Mojo request so it can be document-associated and have the interface include a method for the renderer to provide a remote the browser can use to make calls back to the renderer. 

Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome

--
You received this message because you are subscribed to the Google Groups "services-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to services-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/services-dev/CAPodtY1ZCTMjUgy-OsoP7-ve70mi7Kz-7q5OCrCo1T1N-XQasA%40mail.gmail.com.