Added plumbing to transport the frame name between RenderViewHost and the Webkit layer.

chrome/browser/renderer_host/render_view_host_delegate.h

Index: chrome/browser/renderer_host/render_view_host_delegate.h
diff --git a/chrome/browser/renderer_host/render_view_host_delegate.h b/chrome/browser/renderer_host/render_view_host_delegate.h
index 900ad0f8eabbbf7497754ac05409d99d0666adb4..f3d815e74828fd4409fb53136242c6f43bc54323 100644
--- a/chrome/browser/renderer_host/render_view_host_delegate.h
+++ b/chrome/browser/renderer_host/render_view_host_delegate.h
@@ -93,13 +93,17 @@ class RenderViewHostDelegate {
     // that is requested -- in particular, the window.open call may have
     // specified 'background' and 'persistent' in the feature string.
     //
+    // The passed frame_name parameter is the _name_ parameter that was passed

[rafaelw, 2010/06/10 22:48:05]

nit: The passed frame_name parameter -> |frame_name|; _name_ -> name

+    // to window.open(), and will be empty if none was passed.
+    //
     // Note: this is not called "CreateWindow" because that will clash with
     // the Windows function which is actually a #define.
     //
     // NOTE: this takes ownership of @modal_dialog_event
     virtual void CreateNewWindow(
         int route_id,
-        WindowContainerType window_container_type) = 0;
+        WindowContainerType window_container_type,
+        const string16& frame_name) = 0;
 
     // The page is trying to open a new widget (e.g. a select popup). The
     // widget should be created associated with the given route, but it should
@@ -475,6 +479,10 @@ class RenderViewHostDelegate {
   // Return type of RenderView which is attached with this object.
   virtual ViewType::Type GetRenderViewType() const = 0;
 
+  // Return the desired name of the frame that will be associated with the
+  // RenderView.
+  virtual string16 GetRenderViewFrameName() const { return string16(); }

[rafaelw, 2010/06/10 22:48:05]

This feels kinda wrong. I think providing frame_name to RVH::CreateRenderView
would be more in keeping with the existing code. Is there a reason to prefer
doing it this way? If so, please also just check with Darin or Brettw (they
don't need to review this entire CL -- I'd just wanted to know that they're ok
with this addition to RVHD).

[Andrew T Wilson (Slow), 2010/06/11 04:24:01]

I don't have a strong motivation or preference either way (this was the issue I
emailed you about). Darin didn't have time to look at this right now, but his
brief comments seemed to indicate that he agreed with you, so I'm taking your
suggestion and changing this to be a param passed to CreateRenderView() instead.

+
   // The RenderView is being constructed (message sent to the renderer process
   // to construct a RenderView).  Now is a good time to send other setup events
   // to the RenderView.  This precedes any other commands to the RenderView.