Transfer user agent override info between browser and renderer

content/browser/renderer_host/render_view_host_impl.h

Index: content/browser/renderer_host/render_view_host_impl.h
diff --git a/content/browser/renderer_host/render_view_host_impl.h b/content/browser/renderer_host/render_view_host_impl.h
index cf31bbae19da055fce341f53860e2543c94c4db8..30ed19d09f023715f820fc71e13ec4cd8eee3b8d 100644
--- a/content/browser/renderer_host/render_view_host_impl.h
+++ b/content/browser/renderer_host/render_view_host_impl.h
@@ -244,10 +244,13 @@ class CONTENT_EXPORT RenderViewHostImpl
   // If this RenderView is a guest, the embedder's process ID is also passed in
   // so that the RenderView's process can establish a channel with its embedder
   // if it's not already established.
+  // If |user_agent_override| is non-empty, it overrides the user agent that is
+  // normally used when a navigation requires it.

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

Why is this being done at the level of RenderView creation?  Why not per-page or
per-process?

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

It was defined as a per-navigation setting after several iterations.  (Slightly
out-of-date doc here: http://goto.google.com/chrome_android_rds)

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

Thanks, that helps a lot.  Looks like you want the setting to be turned on
per-tab and then stay on for the lifetime of the tab (unless you go back in
history or turn it off), and you don't want the setting to affect other tabs
opened from the current one.

Unfortunately, that's not quite what's happening, and it doesn't really match
any abstractions we have in the browser.  For example, I'm not sure if the
setting will propagate if you do a cross-process navigation (e.g., typing a
cross-site URL into the omnibox), since that creates a RenderView in a different
process.

Also, it could lead to weird errors if a page opens a popup.  The original page
might try to script the popup, but that might fail bizarrely if they were
requested under different user agents.

Not sure if this is the best place to discuss design decisions, but I wonder if
it makes more sense to preserve the setting for new windows opened by a page.  I
can understand preserving the setting as you navigate cross-site in a tab (from
the user's perspective), though it's a little awkward architecturally.  I bet we
could make it work, though.

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

Seems to work like this on Chrome for Android: when you navigate from
http://slashdot.org to http://cnn.com the flag gets carried across.  I think
we're catching some of the cases where a new RenderView is created and pass the
override info over, but we may not be catching all of them, yet.
I could see this happening, but haven't really hit too many cases on mobile
sites that triggered pop-ups to test with.  I guess this falls under the
child-tab inheritance case below?
We settled on the rules outlined in the doc after a lot of back and forth
(original bug at http://b/5119921, but there was a lot more offline discussion).
 IIRC there was about a 50/50 split on whether to carry the flag over for child
tabs (and even had one iteration where it worked like this), but we ended up
landing the feature as is.  I'd be open to revisiting the decisions, especially
if pop-ups are to be properly handled.  However, it'd be a lot safer to iterate
on this with everything RDS-related upstream.

   virtual bool CreateRenderView(const string16& frame_name,
                                 int opener_route_id,
                                 int32 max_page_id,
-                                int embedder_process_id);
+                                int embedder_process_id,
+                                const std::string& user_agent_override);
 
   base::TerminationStatus render_view_termination_status() const {
     return render_view_termination_status_;