Handle frame openers in the same FrameTree when navigating subframes.

content/browser/web_contents/web_contents_impl.cc

Index: content/browser/web_contents/web_contents_impl.cc
diff --git a/content/browser/web_contents/web_contents_impl.cc b/content/browser/web_contents/web_contents_impl.cc
index f7505af877b67c2644609a9ff6920d39dfba84a0..392e133a63b2c14d733a3b6352d1e77fd1f64bc6 100644
--- a/content/browser/web_contents/web_contents_impl.cc
+++ b/content/browser/web_contents/web_contents_impl.cc
@@ -4149,7 +4149,7 @@ void WebContentsImpl::EnsureOpenerProxiesExist(RenderFrameHost* source_rfh) {
       RenderFrameHostImpl* source_rfhi =
           static_cast<RenderFrameHostImpl*>(source_rfh);
       source_rfhi->frame_tree_node()->render_manager()->CreateOpenerProxies(
-          GetSiteInstance());
+          GetSiteInstance(), nullptr);

[alexmos, 2015/08/25 22:38:08]

Using nullptr keeps today's behavior, but I'm thinking this actually should use
the target's FTN, because if the opener chain of the source node ever leads us
to the target node, we want to make sure not to try to create a proxy for the
target node in its own SiteInstance (given that I've moved the RVH-based
checks).  If you agree, I can add the plumbing to get the target here.  Or maybe
we shouldn't even call EnsureOpenerProxiesExist if AreCrossProcessFramesPossible
is true (in which case all proxies should've already been created).

[Charlie Reis, 2015/08/31 20:49:43]

Interesting.  Is that something we could write a test for?  Sounds worth fixing.

(The downside is that this method's name doesn't sound like it's specific to
postMessage, but in reality I think it is.  The comment in RFHD says it will
even go away once <webview> fixes some postMessage plumbing.  Incidentally, it
also claims the method returns the routing ID, which looks stale.)  :)
That sounds possibly orthogonal.  We could still hit the issue you describe
above with only main frames, right?  Or do the RVH checks in
!AreCrossProcessFramesPossible take care of that?

Given that this method exists for a <webview> special case, then calling it only
when needed might make more sense.

[alexmos, 2015/09/01 22:12:28]

I wrote a test and then realized this is actually fine.  We actually already
have tests that exercise this (specifically, tests that use "postToOpener" will
end up with this scenario when run with --site-per-process), and this works fine
because of this SiteInstance check in CreateProxyForSiteInstance:
https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/fr...

So I don't think we need to change this.
I'll leave this alone for now given my findings above.  

Thinking a bit more, not calling EnsureOpenerProxiesExist if
AreCrossProcessFramesPossible is true isn't actually correct: an example is a 
setup like the SupportCrossProcessPostMessage test, where the swapped-out RVH
needs to be created on-demand when postMessaging the foo window, whether or not
AreCrossProcessFramesPossible is true.  Actually, it will be already created
on-demand due to the window.open("","foo") lookup in the test right before the
postMessage (due to the new opener update logic), but you can imagine
structuring the test slightly differently by getting the foo window reference
from the new_shell2's same-origin opener (main page) instead, in which case
EnsureOpenerProxiesExist would still be necessary.

     }
   }
 }