Partial clone of the following CL: http://codereview.chromium.org/3013045/show

Differences from the above CL include the following:
 - RendererPreferences settings for ExtensionHosts are now extracted from the associated_tab_contents().  This ensures that extension hosts will also forward top level navigation requests.
 - Instead of explicitly setting the delegate on the TabContents in ExtensionHost::ShowCreatedWindow, instead I instruct the associated tab-contents to add the newly build tab-contents.  Note that this is the exact same behaviour performed by TabContents when initiating a top-level navigation to the host browser.  

Points of interest:
 - See the TODO in navigation_controller.cc.  This problem of an unrecognized navigation entry needs further investigation.
 - Also, I found that if the ActiveX control is navigated to a chrome-extension URL, then the top-level-navigation will fail because of the format of the URL.  The fix was to construct a temporary url in place of the chrome-extension url.

BUG=51091
TEST=None 

Review URL: http://codereview.chromium.org/3357013

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@59142 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 6 insertions, 0 deletions

diff --git a/chrome_frame/chrome_frame_activex.cc b/chrome_frame/chrome_frame_activex.cc
index 0401298..e2d9b3a 100644
--- a/chrome_frame/chrome_frame_activex.cc
+++ b/chrome_frame/chrome_frame_activex.cc
@@ -459,6 +459,12 @@ HRESULT ChromeFrameActivex::IOleObject_SetClientSite(
       WideToUTF8(url_, url_.Length(), &utf8_url);
     }
 
+    // Only privileged instances of ActiveX Chrome Frame controls may read
+    // the chrome-network, and top-level-navigation settings from the registry.
+    // See issue: 54920
+    if (is_privileged_)
+      InitializeAutomationSettings();
+
     url_fetcher_->set_frame_busting(!is_privileged_);
     automation_client_->SetUrlFetcher(url_fetcher_.get());
     if (!InitializeAutomation(profile_name, chrome_extra_arguments,