Transfer user agent override info between browser and renderer

content/common/view_messages.h

Index: content/common/view_messages.h
diff --git a/content/common/view_messages.h b/content/common/view_messages.h
index 106954877f7ac09e8bf924714201accb3ca1ba86..a967823bf23a89ef666fb868e1afe049cd5eaf84 100644
--- a/content/common/view_messages.h
+++ b/content/common/view_messages.h
@@ -441,6 +441,12 @@ IPC_STRUCT_BEGIN_WITH_PARENT(ViewHostMsg_FrameNavigate_Params,
 
   // Serialized history item state to store in the navigation entry.
   IPC_STRUCT_MEMBER(std::string, content_state)
+
+  // Original request's URL.
+  IPC_STRUCT_MEMBER(GURL, original_request_url)
+
+  // User agent override used to navigate.
+  IPC_STRUCT_MEMBER(bool, is_overriding_user_agent)
 IPC_STRUCT_END()
 
 // This message is used for supporting popup menus on Mac OS X using native
@@ -628,6 +634,9 @@ IPC_STRUCT_BEGIN(ViewMsg_Navigate_Params)
 
   // Whether or not we should allow the url to download.
   IPC_STRUCT_MEMBER(bool, allow_download)
+
+  // Whether or not the user agent override string should be used.
+  IPC_STRUCT_MEMBER(bool, is_overriding_user_agent)

[Charlie Reis, 2012/06/01 00:36:08]

It's confusing to me that a single string is set for a RenderView and then it's
turned on or off per navigation.  Why not send the string to use on each
navigation?  Seems like that might be better than having state live on the
RenderView.

For example, if the renderer is currently using its local state for
renderer-initiated navigations, but the browser sends a message to change the
user agent while a page is rendering, a single page could have mixed results. 
Is that intended?

[gone, 2012/06/01 01:04:06]

I actually had something working like this downstream, but ended up changing it
around because this way seemed cleaner.  Would a renderer-initiated navigation
(i.e. clicking a link) go through NavigationControllerImpl::LoadURLFromRenderer?
Good point; that's definitely not intended.

[Charlie Reis, 2012/06/01 18:04:09]

Usually it wouldn't.  Only navigations that force a process swap go through
LoadURLFromRenderer, such as clicking a link from a normal page to a hosted app.
 However, that is a case where you'd likely forget the setting.
I'm inclined to think we need a different approach for handling
renderer-initiated navigations, but I'm not sure how to get the correct setting
to WebKit without an IPC to the browser.  Does WebKit actually need to know the
user agent, or is it something the network stack in the browser process could
take care of?  (Hmm, I suppose WebKit needs it in case JavaScript asks for the
user agent.)

[gone, 2012/06/14 00:46:39]

As per our meeting, I'm going to look at whether we can dump the state inside
the WebHistoryItem.
This case is something we probably should handle... I've added the logic
required.
If a user agent override is currently being used for a currently loading page,
changing the override string now requires reloading the page.  Should avoid race
conditions.
WebKit needs to know it for at least user agent checks in JavaScript.

 IPC_STRUCT_END()
 
 IPC_STRUCT_BEGIN(ViewMsg_New_Params)
@@ -659,6 +668,10 @@ IPC_STRUCT_BEGIN(ViewMsg_New_Params)
   // Whether the RenderView should initially be swapped out.
   IPC_STRUCT_MEMBER(bool, swapped_out)
 
+  // The user agent given to WebKit when it requests one and the user agent is
+  // being overridden for the current navigation.
+  IPC_STRUCT_MEMBER(std::string, user_agent_override)
+
   // The initial page ID to use for this view, which must be larger than any
   // existing navigation that might be loaded in the view.  Page IDs are unique
   // to a view and are only updated by the renderer after this initial value.
@@ -732,6 +745,10 @@ IPC_SYNC_MESSAGE_CONTROL0_1(ViewHostMsg_GetCPUUsage,
 IPC_MESSAGE_CONTROL1(ViewMsg_New,
                      ViewMsg_New_Params)
 
+// Set the user agent override used by the renderer.
+IPC_MESSAGE_ROUTED1(ViewMsg_SetUserAgentOverride,
+                    std::string /* override to use */)

[tony, 2012/05/31 17:25:00]

Hmm, should we just add a bool to RendererPreferences instead of adding a new
message?  It looks like RendererPreferences is already passed as part of
ViewMsg_New_Params when creating a new RenderView.

[gone, 2012/05/31 21:43:25]

The RenderView may have already been created when
WebContentsImpl::SetUserAgentOverride() is called, I think.

[tony, 2012/05/31 21:59:02]

That's fine, you would just use ViewMsg_SetRendererPrefs instead.

[gone, 2012/06/14 00:46:39]

If I switch to calling RenderViewImpl::OnSetRendererPrefs() or
RenderViewHost::SyncRendererPrefs(), would there be any fallout from having the
preferences re-set?  RenderViewImpl doesn't seem to change any of these
preferences on its own, so I'd guess it'd be safe.

+
 // Reply in response to ViewHostMsg_ShowView or ViewHostMsg_ShowWidget.
 // similar to the new command, but used when the renderer created a view
 // first, and we need to update it.