diff options
author | ananta@chromium.org <ananta@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2010-03-15 22:14:32 +0000 |
---|---|---|
committer | ananta@chromium.org <ananta@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2010-03-15 22:14:32 +0000 |
commit | dacf0b454dc9395da3ef943b91d2bb482c530623 (patch) | |
tree | 73dcd612bc383bf056b54256e635a074522cff71 /webkit/data | |
parent | 5ee5bef87e0d0ff6506aea55e3310e59ef767b14 (diff) | |
download | chromium_src-dacf0b454dc9395da3ef943b91d2bb482c530623.zip chromium_src-dacf0b454dc9395da3ef943b91d2bb482c530623.tar.gz chromium_src-dacf0b454dc9395da3ef943b91d2bb482c530623.tar.bz2 |
When ChromeFrame switches to IE on receiving the OnHttpEquiv notification indicating the presence of a meta
tag indicating that the page is to be rendered in Chrome, we check if the notification is received for a
site rendered in an IFrame to ensure that we don't switch in this case. This code is not reliable and we end
up assuming that a top level navigation is actually an embedded frame.
Attempting another approach to detect the dummy IWebBrowser2 iframe instances which mshtml creates for top level
navigations which results in the IE to Chrome switch not working reliably.
The location for these dummy browsers is set to about:blank. We now check for the same and ignore these.
I have added comments in the code indicating why we are doing this and the cases where it could break.
It should be fine for most common cases as this code is only hit when the page has a meta tag. Will revisit
this.
This fixes http://code.google.com/p/chromium/issues/detail?id=36825
Bug=36825
Test=Covered by unit test.
Review URL: http://codereview.chromium.org/911003
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@41645 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'webkit/data')
0 files changed, 0 insertions, 0 deletions