Deliver IPC messages together with SwapCompositorFrame

content/browser/renderer_host/render_widget_host_impl.cc

Index: content/browser/renderer_host/render_widget_host_impl.cc
diff --git a/content/browser/renderer_host/render_widget_host_impl.cc b/content/browser/renderer_host/render_widget_host_impl.cc
index 806b0caaaedb9f0d798c268cc5641f0ac6ab2ed9..28bb051ca9ad13799b2ba6106622fa3b13ace2c5 100644
--- a/content/browser/renderer_host/render_widget_host_impl.cc
+++ b/content/browser/renderer_host/render_widget_host_impl.cc
@@ -1462,6 +1462,8 @@ bool RenderWidgetHostImpl::OnSwapCompositorFrame(
   scoped_ptr<cc::CompositorFrame> frame(new cc::CompositorFrame);
   uint32 output_surface_id = param.a;
   param.b.AssignTo(frame.get());
+  std::vector<IPC::Message> messages_to_deliver_with_frame;
+  messages_to_deliver_with_frame.swap(param.c);
 
   for (size_t i = 0; i < frame->metadata.latency_info.size(); i++)
     AddLatencyInfoComponentIds(&frame->metadata.latency_info[i]);
@@ -1487,6 +1489,16 @@ bool RenderWidgetHostImpl::OnSwapCompositorFrame(
     SendSwapCompositorFrameAck(routing_id_, output_surface_id,
                                process_->GetID(), ack);
   }
+
+  RenderProcessHost* rph = GetProcess();
+  for (std::vector<IPC::Message>::const_iterator i =
+           messages_to_deliver_with_frame.begin();
+       i != messages_to_deliver_with_frame.end();
+       ++i) {
+    rph->OnMessageReceived(*i);

[Tom Sepez, 2014/07/02 17:56:04]

You should check if the message was handled, calling BadMessageReceived().

[jam, 2014/07/02 20:10:54]

In general, not handling IPCs is not considered an error. In which case this
would be:

if (i->dispatch_error())
  rph->OnBadMessageReceived(*i);


However, RenderWidget::QueueMessage is somewhat error prone because it only
delivers the queued IPCs to the RPH. That means any IPC currently dispatched by
a BrowserMessageFilter wouldn't work if someone used QueueMessage to send them.

I'm wondering why we need this generic infrastructure. Do we expect more IPCs to
be queued like this? I only see FrameHostMsg_DidFirstVisuallyNonEmptyPaint using
this now, is that correct? If it's just that one IPC, can we do a one-off
solution?

[mkosiba (inactive), 2014/07/03 15:47:32]

Done.
The value of RenderWidget::QueueMessage is that we deliver the messages together
with the frame swap notification, so posting back to the IO thread to run the
filters from here would make it less useful.

Getting message filters to work transparently would essentially require cracking
this message open on the IO thread, filtering the inner messages vector and
forwarding the 'filtered' message on, right?

For now the intent is not to provide a drop-in replacement for IPC.
So I only used DidFirstVisuallyNonEmptyPaint as a guinea pig. I'm working a CL
that uses this mechanism to implement some new webview functionality and piman@
was interested in using this for LatencyInfo and ViewHostMsg_UpdateRect (see
comment #4).

+  }
+  messages_to_deliver_with_frame.clear();
+
   return true;
 }