Change in RenderThread IPC handling?

[Marshall Greenblatt]

Hi All,

Has there been a change in RenderThread IPC handling between M59 and M60?

In my Chromium-based application I'm sending a synchronous IPC message using RenderThread::Get()->Send() from ContentRendererClient::RenderThreadStarted [1] and trying to handle it with an IPC::MessageFilter registered using host->GetChannel()->AddFilter() in ContentBrowserClient::RenderProcessWillLaunch [2]. This worked fine in M59 and earlier but appears to be broken in M60. Specifically, the IPC::MessageFilter never receives the message [3] (MessageFilter::OnMessageReceived is never called) and consequently the renderer process remains blocked at the Send() call.

Since usage of host->GetChannel()->AddFilter() seems uncommon these days I've converted the IPC::MessageFilter to a BrowserMessageFilter using host->AddFilter(), but that didn't fix the problem.

Any suggestions on how to resolve this problem (and/or links to related bugs or CRs) would be greatly appreciated.

Thanks,

Marshall

[1] https://bitbucket.org/chromiumembedded/cef/src/12150b43d2fe01878104e023acd39b73d2db7fca/libcef/browser/content_browser_client.cc?at=master&fileviewer=file-view-default#content_browser_client.cc-455

[2] https://bitbucket.org/chromiumembedded/cef/src/12150b43d2fe01878104e023acd39b73d2db7fca/libcef/browser/content_browser_client.cc?at=master&fileviewer=file-view-default#content_browser_client.cc-448

[3] https://bitbucket.org/chromiumembedded/cef/src/12150b43d2fe01878104e023acd39b73d2db7fca/libcef/browser/browser_message_filter.cc?at=master&fileviewer=file-view-default#browser_message_filter.cc-69

[Ken Rockot]

Looks like this behavior would have been broken by r465462. If you block the main thread from RenderThreadStarted, the IPC Channel will never actually get connected.

Unfortunately we have code in Chrome which now requires this behavior, as it uses RenderThreadStarted to install (the equivalent of) renderer-side IPC filters, and these need to be installed before ChildThreadImpl::StartServiceManagerConnection() is called to avoid raciness. If you need to make something work for now, the thing to do is hack it so your sync IPC comes after StartServiceManagerConnection.

I think we ought to revert back to having a separate ContentRendererClient::ExposeInterfacesToBrowser which we call before StartServiceManagerConnection, and RenderThreadStarted can be moved back to after that call.

Sorry about the trouble -- we obviously have no code in Chrome or other local content embedders which does sync IPC from RenderThreadStarted.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAFW9UJ-E0Oi2dE%2Bn5yGvo-20OUs4sFEMFz9WYX5qXyEd_U%3DsAQ%40mail.gmail.com.

[Marshall Greenblatt]

On Wed, May 31, 2017 at 5:47 PM, Ken Rockot <roc...@chromium.org> wrote:

Looks like this behavior would have been broken by r465462. If you block the main thread from RenderThreadStarted, the IPC Channel will never actually get connected.

Unfortunately we have code in Chrome which now requires this behavior, as it uses RenderThreadStarted to install (the equivalent of) renderer-side IPC filters, and these need to be installed before ChildThreadImpl::StartServiceManagerConnection() is called to avoid raciness. If you need to make something work for now, the thing to do is hack it so your sync IPC comes after StartServiceManagerConnection.

I think we ought to revert back to having a separate ContentRendererClient::ExposeInterfacesToBrowser which we call before StartServiceManagerConnection, and RenderThreadStarted can be moved back to after that call.

Sorry about the trouble -- we obviously have no code in Chrome or other local content embedders which does sync IPC from RenderThreadStarted.

Thanks! I've filed https://crbug.com/728195 and will find a workaround for the time being :)