Re: How to debug flaky Mojo binding

[K. Moon]

Not an expert on any of this, but it sounds to me like the lifetime of your Mojo interface vis-à-vis the state of the renderer isn't well-defined, which is why you're running into problems with frame creation vs. navigation. Maybe it'd help to link to a WIP change or design or something, and someone can suggest an appropriate pattern?

+blink-dev, since this sounds like something a Blink developer would know about.

On Tue, Feb 8, 2022 at 1:18 PM Marshall Greenblatt <magree...@gmail.com> wrote:

The issue appears to be a new navigation that (in M98) results in the following log message:

WARNING:render_frame_host_impl.cc(1196)] InterfaceRequest was dropped, the document is no longer active: my.mojom.MyInterface

From the code (later removed in this commit):

// Logs interface requests that arrive after the frame has already committed a
// non-same-document navigation, and has already unbound
// |broker_receiver_| from the interface connection that had been used to
// service RenderFrame::GetBrowserInterfaceBroker for the previously active
// document in the frame.

The problem, for me, is that ContentRendererClient::RenderFrameCreated is not being called a 2nd time after this new navigation.

Is there a more appropriate renderer process callback for initiating (or retrying) the Mojo binding? For example, should I use something like RunScriptsAtDocumentStart instead?

Thanks,

Marshall

On Mon, Feb 7, 2022 at 5:38 PM Marshall Greenblatt <magree...@gmail.com> wrote:

Hi All,

I have an application running on MacOS (based on Chromium M97) where I'm initiating a Mojo binding from the renderer process and finding that my associated implementation in the browser process is not being executed. Referencing the below example code [1], I've verified that GetInterface is being called in the renderer process but the MyInterfaceImpl object is not being created in the browser process. Complicating matters is that this failure appears to be timing related, in that it succeeds most of the time, but will fail more frequently when the system is under heavy CPU load. I've also been unable to reproduce this failure on Windows using the same code.

Is there a recommended way to debug why a specific Mojo connection is failing? Am I doing anything wrong in the below code that might explain this behavior (wrong usage, wrong callback methods, etc)?

Thanks,

Marshall

[1] Example code:

From ContentRendererClient::RenderFrameCreated in the renderer process:

mojo::Remote<my::mojom::MyInterface> remote;
render_frame->GetBrowserInterfaceBroker()->GetInterface(
    remote.BindNewPipeAndPassReceiver());

remote->ExecuteFoo();  // This message never arrives.

From ContentBrowserClient::RegisterBrowserInterfaceBindersForFrame in the browser process:

map->Add<my::mojom::MyInterface>(base::BindRepeating(
    [](content::RenderFrameHost* frame_host,
       mojo::PendingReceiver<my::mojom::MyInterface> receiver) {

      // This object is never created.

      new MyInterfaceImpl(frame_host, std::move(receiver));
    }));

--
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/CAFW9UJ-9rN1ZbARopY4F%3DcCo35biOaj385NiyQibmTLjZDaxfA%40mail.gmail.com.

[Marshall Greenblatt]

On Tue, Feb 8, 2022 at 4:47 PM K. Moon <km...@chromium.org> wrote:

Not an expert on any of this, but it sounds to me like the lifetime of your Mojo interface vis-à-vis the state of the renderer isn't well-defined, which is why you're running into problems with frame creation vs. navigation. Maybe it'd help to link to a WIP change or design or something, and someone can suggest an appropriate pattern?

+blink-dev, since this sounds like something a Blink developer would know about.

Thanks for bringing in the larger audience. One existing example of my usage pattern (not my code specifically) is CastContentRendererClient::RenderFrameCreated which could presumably experience a similar problem with mojom::ApplicationMediaCapabilities if a navigation occurred.

I'm basically trying to accomplish (in the renderer process) what DocumentService provides in the browser process, but without terminating the mojo connection when the document has finished loading. In other words, a frame-based connection that remains live until that frame is navigated or destroyed.