Fix setting the top-level FrameTreeNode name for named windows.

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 8d60762d70c490a91d04af161250153c78f2d165..ed930379a66a3b8f3935c878d1d0a81355faf0d5 100644
--- a/content/browser/web_contents/web_contents_impl.cc
+++ b/content/browser/web_contents/web_contents_impl.cc
@@ -1204,6 +1204,7 @@ void WebContentsImpl::Init(const WebContents::CreateParams& params) {
   GetRenderManager()->Init(
       params.browser_context, params.site_instance, params.routing_id,
       params.main_frame_routing_id);
+  frame_tree_.root()->SetFrameName(params.main_frame_name);

[Charlie Reis, 2015/05/12 23:45:24]

Could anything in RFHM::Init ever depend on the name?  Just wondering if we need
to move this above it (or if there's a reason to wait until here).

[nasko, 2015/05/13 00:07:27]

SetFrameName actually accesses render_manager_ and sends notifications to all
proxies in it. It sounds incorrect to access an object that hasn't been
initialized yet. Alex and I tried to reason through whether we need the name
during Init and it doesn't seem we do, so decided to leave it this way.

 
   WebContentsViewDelegate* delegate =
       GetContentClient()->browser()->GetWebContentsViewDelegate(this);
@@ -1582,6 +1583,7 @@ void WebContentsImpl::CreateNewWindow(
   CreateParams create_params(GetBrowserContext(), site_instance.get());
   create_params.routing_id = route_id;
   create_params.main_frame_routing_id = main_frame_route_id;
+  create_params.main_frame_name = base::UTF16ToUTF8(params.frame_name);

[Charlie Reis, 2015/05/12 23:45:24]

Why do FrameTreeNode and FrameHostMsg_DidChangeName have a std::string when
ViewHostMsg_CreateWindow_Params has a string16?  Seems like these should have
the same type.

A quick skim shows that WebViewGuest is the one of two places that consume the
string16, and it converts it to a std::string. 
BackgroundContentsService::CreateBackgroundContents is the other, and that
(through some plumbing) passes it to DictionaryValue::SetString, which supports
both string16 and std::string.

Maybe in a separate cleanup CL we can standardize on std::string?

[nasko, 2015/05/13 00:07:27]

Yeah, a separate CL will be fine. I tried doing it on this one, but it did add a
bunch of unrelated changes, so decided to not upload that version.

   create_params.opener = this;
   create_params.opener_suppressed = params.opener_suppressed;
   if (params.disposition == NEW_BACKGROUND_TAB)