summaryrefslogtreecommitdiffstats
path: root/chrome_frame
diff options
context:
space:
mode:
authorananta@chromium.org <ananta@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2010-01-30 00:47:06 +0000
committerananta@chromium.org <ananta@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2010-01-30 00:47:06 +0000
commit18290eb6249c95069b20c3bdfc8163900d2a17a8 (patch)
tree8862c66a30c07241a9c31a0fba185e3c845613c1 /chrome_frame
parent94a3fbfa2fb5da363960d538938e4887e52d1345 (diff)
downloadchromium_src-18290eb6249c95069b20c3bdfc8163900d2a17a8.zip
chromium_src-18290eb6249c95069b20c3bdfc8163900d2a17a8.tar.gz
chromium_src-18290eb6249c95069b20c3bdfc8163900d2a17a8.tar.bz2
In IE8 new windows opened within ChromeFrame via window.open calls at times bypass the host network stack.
In this case we don't get control over the navigation as window.open calls expect to carry the opener relationship over to the new window. This basically means that navigation occurs in Chrome and the new tab/window created by the host attaches to the newly created ExternalTabContainer instance. In IE8 the new tab opens in a new IE process, which basically uses a new automation channel to talk to Chrome. The host network stack implementation routes network requests issued by registered render views to the host browser over the automation channel. There is a timing window between the new window getting created and issuing network requests and the channel being established with the new iexplore instance. As a result network requests issued by the new window don't use the host network stack. Fix is to register the render view and process as a pending view when we get notified about the new TabContents in the original ExternalTabContainers implementation of TabContentsDelegate::AddNewContents. Any network requests issued for this view would result in the corresponding URLRequestAutomationJob instances getting created as pending as well. When the host browser connects to the new ExternalTabContainer instance, we pass over the new automation channel and tab handle to the URLRequestAutomationJob instances and resume them. This fixes bug http://code.google.com/p/chromium/issues/detail?id=33516 Bug=33516 Test=Login to gmail in IE8 in ChromeFrame. Open up a new conversation and click on New Window which opens up a tear off window. This should not bring up the login prompt again. Will think about a good approach to write a unit test for this behavior and send out a separate CL for that. Review URL: http://codereview.chromium.org/554134 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@37585 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'chrome_frame')
-rw-r--r--chrome_frame/test/net/test_automation_provider.cc2
1 files changed, 1 insertions, 1 deletions
diff --git a/chrome_frame/test/net/test_automation_provider.cc b/chrome_frame/test/net/test_automation_provider.cc
index d9cd8db..a9da4d1 100644
--- a/chrome_frame/test/net/test_automation_provider.cc
+++ b/chrome_frame/test/net/test_automation_provider.cc
@@ -84,7 +84,7 @@ URLRequestJob* TestAutomationProvider::Factory(URLRequest* request,
static int new_id = 0x00100000;
URLRequestAutomationJob* job = new URLRequestAutomationJob(request,
g_provider_instance_->tab_handle_, new_id++,
- g_provider_instance_->filter_);
+ g_provider_instance_->filter_, false);
return job;
}
}