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 <https://source.chromium.org/chromium/chromium/src/+/main:chromecast/renderer/cast_content_renderer_client.cc;l=164> 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 <https://source.chromium.org/chromium/chromium/src/+/main:content/public/browser/document_service.h> 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. > > On Tue, Feb 8, 2022 at 1:18 PM Marshall Greenblatt <magreenbl...@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 >> <https://chromium.googlesource.com/chromium/src/+/767ee28b2ebf13276802ca461fe424864dabf740> >> ): >> >> // 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 >> <https://source.chromium.org/chromium/chromium/src/+/main:content/public/renderer/content_renderer_client.h;l=293?q=ContentRendererClient&ss=chromium%2Fchromium%2Fsrc> >> instead? >> >> Thanks, >> Marshall >> >> On Mon, Feb 7, 2022 at 5:38 PM Marshall Greenblatt < >> magreenbl...@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 >>> <https://source.chromium.org/chromium/chromium/src/+/main:content/public/renderer/content_renderer_client.h;l=92?q=ContentRendererClient::RenderFrameCreated&ss=chromium%2Fchromium%2Fsrc> >>> 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 >>> <https://source.chromium.org/chromium/chromium/src/+/main:content/public/browser/content_browser_client.h;l=1125?q=ContentBrowserClient::RegisterBrowserInterfaceBindersForFrame&ss=chromium%2Fchromium%2Fsrc> >>> 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-mojo+unsubscr...@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 >> <https://groups.google.com/a/chromium.org/d/msgid/chromium-mojo/CAFW9UJ-9rN1ZbARopY4F%3DcCo35biOaj385NiyQibmTLjZDaxfA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFW9UJ9sZFx0O6LuoHR%2BEzc3kx2Lbj7F%3DKTzDBLuFpEz4i9ipQ%40mail.gmail.com.
