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 d2237e20bebe5d26de71a8017f7591df98b1840c..3c6f9d4d441371f25905c9779e0be775e72f7498 100644
--- a/content/browser/renderer_host/render_widget_host_impl.cc
+++ b/content/browser/renderer_host/render_widget_host_impl.cc
@@ -1472,6 +1472,16 @@ 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 (std::vector<IPC::Message>::const_iterator i =
+           messages_to_deliver_with_frame.begin();
+       i != messages_to_deliver_with_frame.end();
+       ++i) {
+    GetProcess()->OnMessageReceived(*i);
+  }
+  messages_to_deliver_with_frame.clear();

[piman, 2014/05/20 19:54:05]

Do you need these to be delivered before the OnSwapCompositorFrame?
For the other things I would like to use this for (e.g. the UpdateRect message),
it would make more sense to deliver them after the frame.
It would also slightly alleviate re-entrency concerns if it's at the end of the
method, for example since these messages could be ViewHostMsg_Close or
ViewHostMsg_RenderProcessGone which would end up deleting |this|. For that
reason too, you may want to grab the RenderProcessHost before the loop by the
way (the RPH deletes itself with a DeleteSoon, so there is no risk of it going
away in the loop).

[mkosiba (inactive), 2014/05/22 17:40:24]

nope.
Those are some good points. I'll move the code to the bottom of the method.

 
   for (size_t i = 0; i < frame->metadata.latency_info.size(); i++)
     AddLatencyInfoComponentIds(&frame->metadata.latency_info[i]);