Plumb opener information when creating RenderFrames and RenderFrameProxies for subframes.

content/browser/frame_host/render_frame_host_impl.cc

Index: content/browser/frame_host/render_frame_host_impl.cc
diff --git a/content/browser/frame_host/render_frame_host_impl.cc b/content/browser/frame_host/render_frame_host_impl.cc
index 8aa80c2345d7081ab399ac6dd87285a88719566b..8104531e47defdd244641d94bec5bbc51657129f 100644
--- a/content/browser/frame_host/render_frame_host_impl.cc
+++ b/content/browser/frame_host/render_frame_host_impl.cc
@@ -600,7 +600,8 @@ gfx::NativeViewAccessible
 
 bool RenderFrameHostImpl::CreateRenderFrame(int parent_routing_id,
                                             int previous_sibling_routing_id,
-                                            int proxy_routing_id) {
+                                            int proxy_routing_id,
+                                            int opener_routing_id) {

[Charlie Reis, 2015/08/28 23:27:38]

nit: The ordering here and below is a bit confusing.  Let's make them
consistent.

[alexmos, 2015/08/31 23:54:28]

Done.

   TRACE_EVENT0("navigation", "RenderFrameHostImpl::CreateRenderFrame");
   DCHECK(!IsRenderFrameLive()) << "Creating frame twice";
 
@@ -618,6 +619,7 @@ bool RenderFrameHostImpl::CreateRenderFrame(int parent_routing_id,
   params.parent_routing_id = parent_routing_id;
   params.proxy_routing_id = proxy_routing_id;
   params.previous_sibling_routing_id = previous_sibling_routing_id;
+  params.opener_routing_id = opener_routing_id;

[Charlie Reis, 2015/08/28 23:27:38]

Maybe it should go: routing_id, proxy, opener, parent, previous_sibling?

Proxy corresponds to the same frame as routing_id (which we're about to
replace), and the others are all relationships to other frames.

It would be nice for this to be true throughout this CL, though that may cause
conflicts with dcheng's RenderWidget CL.  (Well, I guess it will conflict either
way.)

[alexmos, 2015/08/31 23:54:28]

Done.  I changed it to follow your suggested order here and elsewhere for
NewFrame.  I similarly fixed the order for NewFrameProxy plumbing to be
"routing_id, view_id, opener, parent".  

I'm actually a bit unsure whether we should put opener before or after parent in
both cases.  Parent seems more important and will be specified in more cases
(whereas opener will be non-null in fairly rare situations), so maybe it should
go first?

[Charlie Reis, 2015/09/01 22:04:26]

I suppose it could also go: routing_id, proxy, parent, previous_sibling, opener.
 The main thing is that routing_id and proxy should be adjacent (since they
refer to the same frame), and parent and previous_sibling should be adjacent
(since they both refer to frame tree relationships).  I could see opener as
state of the frame (thus before the parent/sibling) or less common than frame
tree neighbors (thus after the parent/sibling).

[alexmos, 2015/09/01 23:51:02]

Good reasoning -- I agree both orders make sense.  I don't have a strong
preference, so I'll keep the current order and see if Nasko has thoughts when he
does the IPC review.

   params.replication_state = frame_tree_node()->current_replication_state();
 
   if (render_widget_host_) {