[DRAFT] Create RenderFrameHostManager.

[DRAFT] Create RenderFrameHostManager.

Major changes:
1. Move RenderViewHostManager onto FrameTreeNode.
2. Always create RenderFrameHosts (not just behind a flag).
3. Make RenderViewHostManager swap RenderFrameHosts. (Big change.)
4. Don't create RFH on FrameTreeNode.
5. Give FrameTreeNodes a browser-global ID.
6. Put the frame_tree_node_id on NavigationEntry.
7. Hack to treat cross-process iframe commits as subframes.

[Closed, since these changes have all now landed via smaller CLs.]

BUG=314791

[davidben, 2013-11-18 22:20:50]

Random comment because I noticed there was a ResourceLoader change and was
curious.

https://codereview.chromium.org/30323002/diff/510001/content/browser/loader/r...
File content/browser/loader/resource_loader.cc (right):

https://codereview.chromium.org/30323002/diff/510001/content/browser/loader/r...
content/browser/loader/resource_loader.cc:163: // TODO(creis): Why was this
check here?  Is it a problem for cookies?
I actually came across that line some time ago and looked into this.

It's from http://crrev.com/217113. For sub-frames, set_first_party_for_cookies
probably shouldn't get called because an frame's first-party for cookies should
still be the top-level frame or something like that? Hence the MAIN_FRAME check.

I think neither that target_url parameter nor the set_first_party_for_cookies
call are needed anymore anyway. There is another set_first_party_for_cookies
call in AsyncResourceHandler that comes from the renderer, and the transfer
doesn't happen until after redirects are followed anyway. I never checked at
what point it stopped being necessary, but I would guess some combination of
when the handler chain stopped being rebuilt on transfers and when transfers
stopped happening at every redirect.

[Charlie Reis, 2013-11-18 22:38:14]

On 2013/11/18 22:20:50, David Benjamin wrote:
> I actually came across that line some time ago and looked into this.
> 
> It's from http://crrev.com/217113. For sub-frames, set_first_party_for_cookies
> probably shouldn't get called because an frame's first-party for cookies
should
> still be the top-level frame or something like that? Hence the MAIN_FRAME
check.
> 
> I think neither that target_url parameter nor the set_first_party_for_cookies
> call are needed anymore anyway. There is another set_first_party_for_cookies
> call in AsyncResourceHandler that comes from the renderer, and the transfer
> doesn't happen until after redirects are followed anyway. I never checked at
> what point it stopped being necessary, but I would guess some combination of
> when the handler chain stopped being rebuilt on transfers and when transfers
> stopped happening at every redirect.

Ah, makes sense.  Thanks for looking at it, and I'll have Jochen review the
removal when I get to that part.