ChromeViewMsg_SetIsIncognitoProcess; InterfaceRegistry is not yet bound to a pipe

[Nigel Tao]

I'm Mojofying ChromeViewMsg_SetIsIncognitoProcess in chrome/common/render_messages.h

AFAICT, the only use of that IPC message is from the browser to the renderer, once per renderer, near the start of the renderer process' lifetime. The message is only sent from ChromeContentBrowserClient::RenderProcessWillLaunch:

https://cs.chromium.org/chromium/src/chrome/browser/chrome_content_browser_client.cc?q=ChromeViewMsg_SetIsIncognitoProcess&sq=package:chromium&l=1070&dr=C

which says:

host->Send(new ChromeViewMsg_SetIsIncognitoProcess(profile->IsOffTheRecord()));

On the receiving side, all it does is set an is_incognito_process_ field:

https://cs.chromium.org/chromium/src/chrome/renderer/chrome_render_thread_observer.cc?sq=package:chromium&dr=C&rcl=1478387944&l=299

host is a content::RenderProcessHost*, but naively replacing the host->Send with:

chrome::mojom::IncognitoProcessSetterPtr ips_service;

host->GetRemoteInterfaces()->GetInterface(&ips_service);

fails with:

InterfaceRegistry(service_manager:connector):

  --> InterfaceRegistry is not yet bound to a pipe.

which makes sense, I suppose, as we're inside a function called RenderProcessWillLaunch, so the renderer isn't fully operational yet. But it does make the conversion non-trivial.

Why was the previous IPC OK but the Mojo interface unavailable? Is it because (loosely typed??) old-style IPCs can just sit in a buffer before the receiver is ready to read / dispatch / process?

What approach should I take to Mojofy this? I can think of three options.

1) make a SetIsIncognitoProcess Mojo call at some point later, when the renderer is ready to receive / dispatch / process Mojo calls. But not too late, in case the renderer needs to know that its local is_incognito_process_ field value is correct. When exactly is later but not too late?

2) reverse the flow. Rather than the browser telling the renderer, "you're in incognito mode", have the renderer ask the browser "am I in incognito mode". This could possibly be cached / lazily loaded on the renderer side. (If I'm driving codesearch correctly, I think that this bool is only used by extensions??)

3) this really shouldn't be using Mojo (or old-style IPC) at all. It's one time initialization, conceptually similar to a constructor parameter instead of a setter method. It should really be the equivalent of a command line flag to the renderer process. Chromium noob question: do we have such a mechanism?

Any suggestions?

[Ken Rockot]

On Sat, Nov 5, 2016 at 11:49 PM, Nigel Tao <nige...@chromium.org> wrote:

I'm Mojofying ChromeViewMsg_SetIsIncognitoProcess in chrome/common/render_messages.h

AFAICT, the only use of that IPC message is from the browser to the renderer, once per renderer, near the start of the renderer process' lifetime. The message is only sent from ChromeContentBrowserClient::RenderProcessWillLaunch:

https://cs.chromium.org/chromium/src/chrome/browser/chrome_content_browser_client.cc?q=ChromeViewMsg_SetIsIncognitoProcess&sq=package:chromium&l=1070&dr=C

which says:

host->Send(new ChromeViewMsg_SetIsIncognitoProcess(profile->IsOffTheRecord()));

On the receiving side, all it does is set an is_incognito_process_ field:

https://cs.chromium.org/chromium/src/chrome/renderer/chrome_render_thread_observer.cc?sq=package:chromium&dr=C&rcl=1478387944&l=299

host is a content::RenderProcessHost*, but naively replacing the host->Send with:

chrome::mojom::IncognitoProcessSetterPtr ips_service;

host->GetRemoteInterfaces()->GetInterface(&ips_service);

fails with:

InterfaceRegistry(service_manager:connector):

  --> InterfaceRegistry is not yet bound to a pipe.

which makes sense, I suppose, as we're inside a function called RenderProcessWillLaunch, so the renderer isn't fully operational yet. But it does make the conversion non-trivial.

Why was the previous IPC OK but the Mojo interface unavailable? Is it because (loosely typed??) old-style IPCs can just sit in a buffer before the receiver is ready to read / dispatch / process?

Yes essentially, outgoing messages are queued if sent very early.

 

What approach should I take to Mojofy this? I can think of three options.

1) make a SetIsIncognitoProcess Mojo call at some point later, when the renderer is ready to receive / dispatch / process Mojo calls. But not too late, in case the renderer needs to know that its local is_incognito_process_ field value is correct. When exactly is later but not too late?

2) reverse the flow. Rather than the browser telling the renderer, "you're in incognito mode", have the renderer ask the browser "am I in incognito mode". This could possibly be cached / lazily loaded on the renderer side. (If I'm driving codesearch correctly, I think that this bool is only used by extensions??)

3) this really shouldn't be using Mojo (or old-style IPC) at all. It's one time initialization, conceptually similar to a constructor parameter instead of a setter method. It should really be the equivalent of a command line flag to the renderer process. Chromium noob question: do we have such a mechanism?

Any suggestions?

There is another issue here which you need to consider: there's almost definitely an implicit dependency on this message arriving in the renderer before other legacy IPC messages, so sticking it on an arbitrary mojo interface on its own message pipe is probably doomed to introduce subtle bugs. 

While I think making this a command-line argument instead of IPC seems reasonable, I don't have any context for why it was done with IPC. Maybe there's a good reason, maybe not.

In any case, we have Channel-associated interfaces (documentation is still a TODO for me, sorry) which allow you to define messages in arbitrary mojom interfaces but use the legacy IPC channel as the underlying transport for those interfaces. These interfaces are then able to transparently queue early messages like legacy IPC, and of course they also guarantee FIFO with respect to legacy IPC.

For one example there's the Renderer Channel-associated interface -- this is just a bag of miscellaneous browser-to-renderer messages which have been converted. It's accessible via RenderProcessHost::GetRendererInterface and is safe to call into very early.

You could mimic this approach for messages like SetIsIncognitoProcess, but since it's in the src/chrome layer you'll need to introduce a new interface and bind it somewhere in the renderer. Something I've been meaning to do is add support in RenderThreadImpl::OnAssociatedInterfaceRequest to let RenderThreadObservers take a shot at handling incoming requests. Then you could have ChromeRenderThreadObserver implement some new mojom and stuff the message there.

 

--
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+unsubscribe@chromium.org.
To post to this group, send email to chromi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-mojo/CAEdON6aNUzg6HZv7N2eZNSwAcUTuLjYheZ6XVTC0hjavdJ4qdw%40mail.gmail.com.

[Nigel Tao]

On Sun, Nov 6, 2016 at 7:14 PM, Ken Rockot <roc...@chromium.org> wrote:
> While I think making this a command-line argument instead of IPC seems
> reasonable, I don't have any context for why it was done with IPC. Maybe
> there's a good reason, maybe not.

Ah, even if ChromeViewMsg_SetIsIncognitoProcess, a simple boolean,
could be done as a command-line argument, the
ChromeViewMsg_SetContentSettingRules IPC message looks similar in
terms of timing (being sent during RenderProcessWillLaunch), but would
be more awkward to serialize via the command line.

I suppose I need to do some more reading about associated interfaces,
or try the "reverse the flow" technique.

[Nigel Tao]

On Sun, Nov 6, 2016 at 7:14 PM, Ken Rockot <roc...@chromium.org> wrote:

> In any case, we have Channel-associated interfaces (documentation is still a
> TODO for me, sorry) which allow you to define messages in arbitrary mojom
> interfaces but use the legacy IPC channel as the underlying transport for
> those interfaces. These interfaces are then able to transparently queue
> early messages like legacy IPC, and of course they also guarantee FIFO with
> respect to legacy IPC.

Out of curiosity... what's the plan then when the glorious future
comes and we eliminate all of the legacy IPC messages? Will we still
have to keep that legacy IPC channel around?

Also, curious... when these early messages are queued, they sit in the
sender's (the browser's) buffer, not the receiver's (the renderer's)
buffer, right? Is the sender's buffer's size bounded?

> You could mimic this approach for messages like SetIsIncognitoProcess, but
> since it's in the src/chrome layer you'll need to introduce a new interface
> and bind it somewhere in the renderer. Something I've been meaning to do is
> add support in RenderThreadImpl::OnAssociatedInterfaceRequest to let
> RenderThreadObservers take a shot at handling incoming requests. Then you
> could have ChromeRenderThreadObserver implement some new mojom and stuff the
> message there.

OK, I mailed out https://codereview.chromium.org/2531133002/ and I'm
not sure if that's exactly what you meant (I didn't touch
RenderThreadImpl::OnAssociatedInterfaceRequest per se), but it seems
to work.