summaryrefslogtreecommitdiffstats
path: root/chrome_frame/urlmon_moniker.cc
Commit message (Collapse)AuthorAgeFilesLines
* Avoid wrapping callbacks for network requests not coming from MSHTML.stoyan@chromium.org2010-05-201-0/+19
| | | | | | | | | This is a tentative fix, since I was unable to reproduce crash in AcroPDF.dll Review URL: http://codereview.chromium.org/2087017 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@47813 0039d316-1c4b-4281-b951-d872f2087c98
* Candidate fix for bug 44108. The FromBindContext function was inherently ↵tommi@chromium.org2010-05-141-9/+11
| | | | | | | | | | | | | racy as it returned a pointer to a non-addrefed pointer and the AddRef/Release implementation in the BindContextInfo was not thread safe. Also fixed BSCBStorageBind object leak. TEST=See bug description BUG=44108 Review URL: http://codereview.chromium.org/2080005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@47306 0039d316-1c4b-4281-b951-d872f2087c98
* ChromeFrame would not switch to Chrome at times. The navigation manager in ↵ananta@chromium.org2010-05-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | ChromeFrame maintains the current top level URL which is used by the moniker patch to decide whether to wrap the callback. This url is typically set in the Bho in the BeforeNavigate callback. We also had code to update this url when we receive a navigation update from Chrome. The reason we would not switch is because of a race condition between receiving a top level navigation request from chrome and receiving a navigation update for the previous operation which caused us to not wrap the bind status callback. Fix is to not update the url in the callback when we receive a navigation status update. In any case it is Chrome's responsibility to inform ChromeFrame about top level url navigations. We should fix the bug if any in Chrome which caused this hack to go in. Fixes bug http://code.google.com/p/chromium/issues/detail?id=43922 Other changes are to replace the NOTREACHED in the chrome frame automation proxy code with a DLOG as this fires during chrome frame test runs. Bug=43922 Review URL: http://codereview.chromium.org/1991008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@47086 0039d316-1c4b-4281-b951-d872f2087c98
* Another attempt to reduce the number of false positive crashes reported in ↵ananta@chromium.org2010-05-071-7/+3
| | | | | | | | | | | | | | | | | | ChromeFrame. There appear to be a number of crashes caused when we wrap the bind status callback and call the underlying IMoniker::BindToStorage function. The crashes occur because of urlmon calling into dlls which have been unloaded. Fix is to use the exception barrier version which only reports crashes which occur directly in chrome frame in our BindtoStorage call and to use the generic ExceptionBarrier in our bind status callback wrapper before calling out to the underlying callback. Fixes bug http://code.google.com/p/chromium/issues/detail?id=43373 Bug=43373 Review URL: http://codereview.chromium.org/2002009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@46742 0039d316-1c4b-4281-b951-d872f2087c98
* Avoid reporting crashes for exceptions that hit our SEH from calls to the ↵robertshield@chromium.org2010-05-011-3/+6
| | | | | | | | | | | | original implementation of BindToStorage() when we do not wrap the bind status callback. BUG=42660 TEST=Induce exception in code called under original IMoniker::BindToStorage implementation when we don't wrap the callback and notice that no crash is reported. Review URL: http://codereview.chromium.org/1748016 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@46176 0039d316-1c4b-4281-b951-d872f2087c98
* Fresh ChromeFrame installs triggered via wave required IE to be restarted ↵ananta@chromium.org2010-04-291-1/+13
| | | | | | | | | | | | | | | | | for wave to switch to Chrome in the current page/tab. The ChromeFrame install flow instantiates the ChromeFrame ActiveX which ensures that the IMoniker patches are in place for switching to work. However ChromeFrame relies on the BHO to be loaded in order to determine that a URL is a top level URL. The ChromeFrame ActiveX now attempts to load the BHO dynamically and registers it with the top level IWebBrowser for the page. This fixes bug http://code.google.com/p/chromium/issues/detail?id=42790 Bug=42790 Review URL: http://codereview.chromium.org/1789007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@45969 0039d316-1c4b-4281-b951-d872f2087c98
* Add an ExceptionBarrier around outbound calls to patched methods in IE. In ↵robertshield@chromium.org2010-04-281-2/+10
| | | | | | | | | | | | so doing, we have an SEH present in the SEH chain and so the VEH won't erroneously report crashes that occur in other modules when we happen to be on the stack. BUG=42660 TEST=Less false positives in the crash reports. Review URL: http://codereview.chromium.org/1733021 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@45764 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 44897 - Improved compatibility support for IE8.tommi@chromium.org2010-04-191-1/+1
| | | | | | | | | | | | | | | | | | | | 1) We no longer add a user agent to requests that do not already have one. This will result in the correct user agent header being applied but it will not have the chromeframe tag. Requests that will be affected include requests from other plugins and XHR but not top level requests. 2) Requests from Chrome Frame will always have the native user agent applied regardless of compatibility settings. This means that in IE8, you will always see CF requests with MSIE 8.0 even though the target site is otherwise configured to run in IE7 compatibility. TEST=Make sure all CF websites continue to work properly. Also, turn on IE7 compatibility mode for some websites (e.g. wave, vimeo) and check if the user agent sent to those sites contains "MSIE 7.0" for pages that are not rendered in CF. Pages rendered in CF should always have the IE8 header with the possible exception of the very first request if that request was issued by mshtml. BUG=28816 Review URL: http://codereview.chromium.org/1521037 TBR=tommi@chromium.org Review URL: http://codereview.chromium.org/1659008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@44919 0039d316-1c4b-4281-b951-d872f2087c98
* Improved compatibility support for IE8.tommi@chromium.org2010-04-181-1/+1
| | | | | | | | | | | | | | | | | 1) We no longer add a user agent to requests that do not already have one. This will result in the correct user agent header being applied but it will not have the chromeframe tag. Requests that will be affected include requests from other plugins and XHR but not top level requests. 2) Requests from Chrome Frame will always have the native user agent applied regardless of compatibility settings. This means that in IE8, you will always see CF requests with MSIE 8.0 even though the target site is otherwise configured to run in IE7 compatibility. TEST=Make sure all CF websites continue to work properly. Also, turn on IE7 compatibility mode for some websites (e.g. wave, vimeo) and check if the user agent sent to those sites contains "MSIE 7.0" for pages that are not rendered in CF. Pages rendered in CF should always have the IE8 header with the possible exception of the very first request if that request was issued by mshtml. BUG=28816 Review URL: http://codereview.chromium.org/1521037 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@44897 0039d316-1c4b-4281-b951-d872f2087c98
* With the ChromeFrame IMoniker patch in the referrer would not propagate ↵ananta@chromium.org2010-04-161-51/+1
| | | | | | | | | | | | | | | | | | | | correctly to Chrome when we switch from IE to CF. In ChromeFrame the referrer is set in the navigation manager which receives this in the IHttpNegotiate::BeginningTransaction patch. When we switch from IE to cF via the moniker patch we receive two calls to BeginningTransaction, the first one with the referrer and the other one without the referrer for the same URL causing the referrer to be overwritten. Fix is to handle this case. The referrer is cleared in our BeforeNavigate notification. I also moved some functions to chrome frame utils as part of this CL. Fixes bug http://code.google.com/p/chromium/issues/detail?id=41680 Bug=41680 Review URL: http://codereview.chromium.org/1653006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@44733 0039d316-1c4b-4281-b951-d872f2087c98
* Avoid a crash in ChromeFrame in the BindToStorage call initiated when our ↵ananta@chromium.org2010-04-151-74/+24
| | | | | | | | | | | | | | | | active document is loaded. The crash occurs while dereferencing a NULL delegate which is the case in the pending request object created by the active document to handle the initial load. Fix for this is to maintain a pending state in the request object. We ignore all OnProgress notifications in this state. When Chrome requests data for the top level url this state is cleared. Consolidated the number of bind context information structures into one which contains everything we need in ChromeFrame, i.e. to decide to switch to Chrome, indicating whether the request came from Chrome, etc. Review URL: http://codereview.chromium.org/1654012 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@44604 0039d316-1c4b-4281-b951-d872f2087c98
* Fix for remaining major issues with moniker patchamit@chromium.org2010-04-141-16/+46
| | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes things so that they now work 'naturally', i.e switch to chrome frame looks just like switching to pdf. The same bind context and underlying network transaction objects are used and requests aren't sent multiple times. Finally the TestPostReissue test is happy! This patch fixes two issues with earlier scheme: Issue 1: data can be read only once from a given bind context. Mshtml looks at the mime type in the FORMATETC but never issues a read. So when it switches, the new active document can read from start. Since we are reading the data for switching, when we actually switch, we have to transfer over the data read so far to our UrlmonUrlRequest. Issue 2: The very first UrlmomUrlRequest has to start binding right away, in the context of BindToStorage or network transcations associated with the bind context are gone (due to OnStopBinding for BindToObject). TEST=covered by existing tests BUG=33332 Review URL: http://codereview.chromium.org/1508033 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@44427 0039d316-1c4b-4281-b951-d872f2087c98
* IE would not switch into ChromeFrame if the url being navigated to had an ↵ananta@chromium.org2010-04-131-2/+6
| | | | | | | | | | | | | | | | | | | | anchor. The IsTopLevelUrl function exposed by the navigation manager would compare the URL received in the BHO which has the anchor and the URL received from the anchor which does not have the anchor. As a result we would not wrap the bind status callback which caused this issue. The IsTopLevelUrl function now compares the URLs after stripping the anchor portion in the URL. Should fix bug http://code.google.com/p/chromium/issues/detail?id=38265. This only works if the moniker patch is enabled. Bug=38265 Test=Covered by unit test. Review URL: http://codereview.chromium.org/1559027 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@44309 0039d316-1c4b-4281-b951-d872f2087c98
* Fix incorrect condition for renderer switching.amit@chromium.org2010-04-121-1/+1
| | | | | | | | | TBR=ananta TEST=covered by existing tests. Review URL: http://codereview.chromium.org/1600022 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@44279 0039d316-1c4b-4281-b951-d872f2087c98
* Further improvments in IE switchingamit@chromium.org2010-04-121-56/+34
| | | | | | | | | | | | | | | | Manually loading active document in IMoniker::BindToObject does not work in IE6. The binding is not initialized and directly calling BindToStorage on it just does not return the data. The solution is to register ActiveDoc's CLSID as handler for 'text/html' mime type in the bind context marked for switching. Urlmon will correctly instantiate it them BUG=none TEST=covered by existing tests. Review URL: http://codereview.chromium.org/1595021 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@44274 0039d316-1c4b-4281-b951-d872f2087c98
* Fix IE6 switching issuesananta@chromium.org2010-04-091-8/+32
| | | | | | | | | | | Fixes for issues with new moniker patch. BUG=none TEST=covered by existing tests Review URL: http://codereview.chromium.org/1625010 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@44160 0039d316-1c4b-4281-b951-d872f2087c98
* Switch renderer in Moniker patchamit@chromium.org2010-04-091-431/+94
| | | | | | | | | | Step one of the changes. Inspect data and cause a switch in the moniker patch. Review URL: http://codereview.chromium.org/1589013 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@44038 0039d316-1c4b-4281-b951-d872f2087c98
* Fix a ChromeFrame crash which occurs probably in the upgrade scenario where ↵ananta@chromium.org2010-04-021-1/+4
| | | | | | | | | | | | | | | we fail to cocreate our active document object which was most likely unregistered. Added a check to bail here. Fixes bug http://code.google.com/p/chromium/issues/detail?id=40169 Bug=40169 Review URL: http://codereview.chromium.org/1564008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@43456 0039d316-1c4b-4281-b951-d872f2087c98
* Don't assume that the mime type for documents that mshtml rejects is CF(!)tommi@chromium.org2010-03-261-1/+1
| | | | | | | | | TEST=If a web site reports a content type that mshtml cannot render (e.g application/text, application/pdf etc) we didn't have a check for our mime type. BUG=none Review URL: http://codereview.chromium.org/976007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42706 0039d316-1c4b-4281-b951-d872f2087c98
* Make (&CGID_Explorer, SBCMDID_MIXEDZONE) command more sane.stoyan@chromium.org2010-03-241-3/+4
| | | | | | | Add test for navigation to sites in restricted sites zone. Review URL: http://codereview.chromium.org/1217001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42484 0039d316-1c4b-4281-b951-d872f2087c98
* Fix ChromeFrame referrer test which was flaky due to incorrect http header ↵ananta@chromium.org2010-03-231-5/+2
| | | | | | | | | | | | | | | | | | | | | | | | | parsing. To pass the referrer to Chrome during navigation we were converting normalized HTTP headers which are terminated with \r\n to raw headers and attempting to parse them. Converting to raw headers basically replaces \r\n with the NULL terminator which causes the parsing to fail as a result of which we fail to retrieve the referrer. Fix is to not convert the headers to raw and just parse the orignal headers. The other change is to only flag success or failure in the referrer frame test if we are running in Chrome. This page loads initially in IE as well due to the vagaries of the http equiv patch. Flagging an error if we don't find a referrer basically causes the test to fail. This should fix http://code.google.com/p/chromium/issues/detail?id=34812 Will remove the flaky attribute on the ChromeFrame Referrer test in a subsequent CL if all goes well. Bug=34812 Review URL: http://codereview.chromium.org/1128013 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42372 0039d316-1c4b-4281-b951-d872f2087c98
* Fix a crash with the IMoniker::BindToObject patch in ChromeFrame which ↵ananta@chromium.org2010-03-191-32/+37
| | | | | | | | | | | | | occurs during View Source. The crash occurs because we don't have a NavigationManager instance. Fix is to just call the original BindToObject method and bail. Review URL: http://codereview.chromium.org/1133003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42044 0039d316-1c4b-4281-b951-d872f2087c98
* IE6 would not switch to ChromeFrame if the url being navigated to contained ↵ananta@chromium.org2010-03-161-0/+1
| | | | | | | | | | | | | | | | | | | | | an anchor. This is presumably because from IE6's perspecive nothing changed. To workaround this issue, we stash the complete url away in the navigation manager and remove it from the URL being navigated to. When the Chrome active document loads we read the actual url from the navigation manager and initiate a navigation to this URL. There is one issue with this approach though. The actual URL in the address bar in IE6 does not contain the anchor tag. Will address that in a follow up CL. This fixes bug http://code.google.com/p/chromium/issues/detail?id=38265 Bug=38265 Test=Covered by existing ChromeFrame anchor URL navigation tests. Review URL: http://codereview.chromium.org/1022003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@41776 0039d316-1c4b-4281-b951-d872f2087c98
* Fix #1 for multiple request issue (both POST and GET) after activating the ↵tommi@chromium.org2010-03-121-0/+609
onhttpequiv approach. There's a ton going on here. Brief summary: I'm introducing a caching layer for top level page requests that we then use again when switching the document from mshtml to cf. Also in this change list: * Removing the previous way of shifting the document moniker over to the worker thread when a new chrome document is created. Instead we use a request cache object. * Refactoring the part of the Bho class that offered access to it via TLS. This was needed for better testability but also makes (imho) the separation clearer and will possibly help in the future if we don't have a Bho object. * Added a bit of logging that I'd prefer to keep in there until we're confident enough with onhttpequiv. * Enabling two previously disabled tests (the ones I added for multiple requests) * Adding several more unit tests for the new code. Review URL: http://codereview.chromium.org/668187 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@41495 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-01-18 19:38:27 +0000