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 /chrome_frame/bho.cc | |
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 'chrome_frame/bho.cc')
-rw-r--r-- | chrome_frame/bho.cc | 40 |
1 files changed, 38 insertions, 2 deletions
diff --git a/chrome_frame/bho.cc b/chrome_frame/bho.cc index c5c8aa0..aa333b7 100644 --- a/chrome_frame/bho.cc +++ b/chrome_frame/bho.cc @@ -165,8 +165,44 @@ bool DocumentHasEmbeddedItems(IUnknown* browser) { if (enumerator) { ScopedComPtr<IUnknown> unk; DWORD fetched = 0; - enumerator->Next(1, unk.Receive(), &fetched); - has_embedded_items = (fetched != 0); + while (!has_embedded_items && + SUCCEEDED(enumerator->Next(1, unk.Receive(), &fetched)) + && fetched) { + // If a top level document has embedded iframes then the theory is + // that first the top level document finishes loading and then the + // iframes load. We should only treat an embedded element as an + // iframe if it supports the IWebBrowser interface. + ScopedComPtr<IWebBrowser2> embedded_web_browser2; + if (SUCCEEDED(embedded_web_browser2.QueryFrom(unk))) { + // If we initiate a top level navigation then at times MSHTML + // creates a temporary IWebBrowser2 interface which basically shows + // up as a temporary iframe in the parent document. It is not clear + // as to how we can detect this. I tried the usual stuff like + // getting to the parent IHTMLWindow2 interface. They all end up + // pointing to dummy tear off interfaces owned by MSHTML. + // As a temporary workaround, we found that the location url in + // this case is about:blank. We now check for the same and don't + // treat it as an iframe. This should be fine in most cases as we + // hit this code only when the actual page has a meta tag. However + // this would break for cases like the initial src url for an + // iframe pointing to about:blank and the page then writing to it + // via document.write. + // TODO(ananta) + // Revisit this and come up with a better approach. + ScopedBstr location_url; + embedded_web_browser2->get_LocationURL(location_url.Receive()); + + std::wstring location_url_string; + location_url_string.assign(location_url, location_url.Length()); + + if (!LowerCaseEqualsASCII(location_url_string, "about:blank")) { + has_embedded_items = true; + } + } + + fetched = 0; + unk.Release(); + } } } } |