summaryrefslogtreecommitdiffstats
path: root/chrome_frame
Commit message (Collapse)AuthorAgeFilesLines
* Enabling the onhttpequiv detection and temporarily disabling a few tests ↵tommi@chromium.org2010-01-192-5/+15
| | | | | | | | | | | that will fail for a day or two while we adapt. TEST=Run all unit tests. BUG=none Review URL: http://codereview.chromium.org/552038 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36507 0039d316-1c4b-4281-b951-d872f2087c98
* Updates for onhttpequiv. Preserving the referrer header, zapping the ↵tommi@chromium.org2010-01-165-16/+102
| | | | | | | | | | | | | currently loading document to prevent small documents from executing code. I'm not enabling httpequiv just yet as there are a couple of things I'm working on related to tests that will break once I make the switch. TEST=There should be no change since the code isn't still active but run all tests just to be safe. BUG=none Review URL: http://codereview.chromium.org/545096 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36436 0039d316-1c4b-4281-b951-d872f2087c98
* Changing DLOG to LOG for tests so that we'll get the errors in the test run ↵tommi@chromium.org2010-01-152-16/+21
| | | | | | | | | | | logs. TEST=n/a BUG=none Review URL: http://codereview.chromium.org/552018 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36420 0039d316-1c4b-4281-b951-d872f2087c98
* Suppress crash dump generation due to IsBadXXX functions.amit@chromium.org2010-01-156-44/+127
| | | | | | | | | | | | | IsBad[Read/Write]Ptr etc functions cause access violations which we catch and take crash dump if we are on stack. Adding code to suppress these false positives. BUG=none TEST=added new tests cases to ChromeFrame.ExceptionReport Review URL: http://codereview.chromium.org/536073 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36403 0039d316-1c4b-4281-b951-d872f2087c98
* Mark WidgetModeIE_CFInstancefrPost and WidgetModeIE_PriviligedApis as flakyjshin@chromium.org2010-01-151-2/+4
| | | | | | | | BUG=32321 TBR=ananta Review URL: http://codereview.chromium.org/543071 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36317 0039d316-1c4b-4281-b951-d872f2087c98
* Fix chrome_frame build by updating build files.phajdan.jr@chromium.org2010-01-132-7/+0
| | | | | | | | | BUG=10840 TBR=maruel Review URL: http://codereview.chromium.org/536044 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36120 0039d316-1c4b-4281-b951-d872f2087c98
* Make running chrome process detection in ui tests more reliable.phajdan.jr@chromium.org2010-01-131-24/+7
| | | | | | | | | | | Also drops fragile code. TEST=Covered by ui_tests. BUG=10840 Review URL: http://codereview.chromium.org/545006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36119 0039d316-1c4b-4281-b951-d872f2087c98
* Flick the switch back to PATCH_PROTOCOL while sorting out a few failing unit ↵tommi@chromium.org2010-01-121-1/+1
| | | | | | | | | tests on the builder. TBR=robertshield git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36010 0039d316-1c4b-4281-b951-d872f2087c98
* Querying for one more interface to handle IE8 on XP case. This is what we ↵tommi@chromium.org2010-01-123-39/+32
| | | | | | | | | | | | were hitting on the builder. R=ananta BUG=none TEST=Run all unit tests. This is a second attempt to switch to onhttpequiv. Review URL: http://codereview.chromium.org/543017 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36009 0039d316-1c4b-4281-b951-d872f2087c98
* Support the PUT HTTP verb in ChromeFrame in the IE host network stack ↵ananta@chromium.org2010-01-111-10/+20
| | | | | | | | | | | | | | | | | | implementation. This verb is supported in the Chrome network stack. Added a urlrequest test for the HTTP PUT verb and corresponding support in the HTTP test server. Fixes bug http://code.google.com/p/chromium/issues/detail?id=31629 Bug=31629 Test=Covered by net tests. Review URL: http://codereview.chromium.org/538012 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35922 0039d316-1c4b-4281-b951-d872f2087c98
* Marking the following tests as flaky.ananta@chromium.org2010-01-081-2/+6
| | | | | | | | | | | | 1. FullTabModeIE_ChromeFrameKeyboardTest 2. FullTabModeIE_BackForwardAnchor Bug=26549 TBR=amit Review URL: http://codereview.chromium.org/533002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35849 0039d316-1c4b-4281-b951-d872f2087c98
* Fix chrome frame net tests that were failing on some machines. Checking in ↵tommi@chromium.org2010-01-081-1/+7
| | | | | | | | | | | straight away as per Robert's request. TEST=run the net tests for chrome frame. BUG=none TBR=robertshield Review URL: http://codereview.chromium.org/527034 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35794 0039d316-1c4b-4281-b951-d872f2087c98
* Correct Chrome Frame dependencies such that a) CF tests depend on the CF DLL ↵robertshield@chromium.org2010-01-081-6/+3
| | | | | | | | | | | b) all.gyp:chromium_builder will build CF stuff. BUG=CF dll and chrome_launcher.exe were not getting built on the chromium-rel builder. TEST=No more BUG. Review URL: http://codereview.chromium.org/517065 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35788 0039d316-1c4b-4281-b951-d872f2087c98
* Attempt 2 at landing this.ananta@chromium.org2010-01-089-166/+311
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Deleting cookies by setting the expires attribute on them with an empty value would not work in ChromeFrame with the host network stack enabled. When we receive a response in the host browser (IE) we send over the response headers which include the Set-Cookie header and a list of cookies retreived via the InternetGetCookie API. We call this API to retrieve the persistent cookies and send them over to Chrome. However this API returns session cookies as well as persistent cookies. There is no documented way to return only persistent cookies from IE. As a result we would end up setting duplicate cookies in Chrome, which caused this issu.e. To workaround this issue when we receive the response in the url request automation job which handles ChromeFrame network requests, we strip out duplicate cookies sent via InternetGetCookie. When a script deletes a cookie we now handle it correctly in IE and set the data to an empty string. However this does not delete the cookie. When such cookies show up in Chrome, we strip them out as well. Fixes bug http://code.google.com/p/chromium/issues/detail?id=30786 The changes to chrome_frame_npapi.cc/.h are to move the NPAPI functions to the chrome_frame namespace as they conflict with similar functions in NACL. Added the DeleteCookie function to the CookieStore interface, which I think missed out by oversight. Bug=30786 Test=Covered by ChromeFrame unit tests. I also added a unit test to test the newly added URLRequestAutomationJob::IsCookiePresentInCookieHeader function TBR=amit Review URL: http://codereview.chromium.org/521072 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35778 0039d316-1c4b-4281-b951-d872f2087c98
* Reason:tyoshino@chromium.org2010-01-089-311/+166
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Linux Builder (ChromiumOS) failed. http://chrome-buildbot.corp.google.com:8010/builders/Linux%20Builder%20(ChromiumOS)/builds/2050/steps/compile/logs/stdio Please add changes to external_cookie_handler_unittest.cc no to break compilation and reland? ---- Revert 35769 - Deleting cookies by setting the expires attribute on them with an empty value would not work in ChromeFrame with the host network stack enabled. When we receive a response in the host browser (IE) we send over the response headers which include the SetCookie header and a list of cookies retreived via the InternetGetCookie API. We call this API to retrieve the persistent cookies and send them over to Chrome. However this API returns session cookies as well as persistent cookies. There is no documented way to return only persistent cookies from IE. As a result we would end up setting duplicate cookies in Chrome, which caused this issu.e. To workaround this issue when we receive the response in the url request automation job which handles ChromeFrame network requests, we strip out duplicate cookies sent via InternetGetCookie. When a script deletes a cookie we now handle it correctly in IE and set the data to an empty string. However this does not delete the cookie. When such cookies show up in Chrome, we strip them out as well. Fixes bug http://code.google.com/p/chromium/issues/detail?id=30786 The changes to chrome_frame_npapi.cc/.h are to move the NPAPI functions to the chrome_frame namespace as they conflict with similar functions in NACL. Added the DeleteCookie function to the CookieStore interface, which I think missed out by oversight. Bug=30786 Test=Covered by ChromeFrame unit tests. I also added a unit test to test the newly added URLRequestAutomationJob::IsCookiePresentInCookieHeader function Review URL: http://codereview.chromium.org/518054 TBR=ananta@chromium.org Review URL: http://codereview.chromium.org/517070 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35771 0039d316-1c4b-4281-b951-d872f2087c98
* Deleting cookies by setting the expires attribute on them with an empty ↵ananta@chromium.org2010-01-089-166/+311
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | value would not work in ChromeFrame with the host network stack enabled. When we receive a response in the host browser (IE) we send over the response headers which include the Set-Cookie header and a list of cookies retreived via the InternetGetCookie API. We call this API to retrieve the persistent cookies and send them over to Chrome. However this API returns session cookies as well as persistent cookies. There is no documented way to return only persistent cookies from IE. As a result we would end up setting duplicate cookies in Chrome, which caused this issu.e. To workaround this issue when we receive the response in the url request automation job which handles ChromeFrame network requests, we strip out duplicate cookies sent via InternetGetCookie. When a script deletes a cookie we now handle it correctly in IE and set the data to an empty string. However this does not delete the cookie. When such cookies show up in Chrome, we strip them out as well. Fixes bug http://code.google.com/p/chromium/issues/detail?id=30786 The changes to chrome_frame_npapi.cc/.h are to move the NPAPI functions to the chrome_frame namespace as they conflict with similar functions in NACL. Added the DeleteCookie function to the CookieStore interface, which I think missed out by oversight. Bug=30786 Test=Covered by ChromeFrame unit tests. I also added a unit test to test the newly added URLRequestAutomationJob::IsCookiePresentInCookieHeader function Review URL: http://codereview.chromium.org/518054 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35769 0039d316-1c4b-4281-b951-d872f2087c98
* Histograms sent out to Chrome need to have the kIPCSerializationSourceFlag ↵ananta@chromium.org2010-01-071-0/+1
| | | | | | | | | | flag set. Not having this flag causes a DCHECK to fire. Review URL: http://codereview.chromium.org/519077 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35739 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting back to patching the protocol handlers to get the builder green again.ananta@chromium.org2010-01-071-1/+1
| | | | | | | | TBR=tommi Review URL: http://codereview.chromium.org/527020 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35724 0039d316-1c4b-4281-b951-d872f2087c98
* Enable the HTTP Equiv patch by default and disable the InternetProtocol patches.tommi@chromium.org2010-01-071-1/+1
| | | | | | | | | TEST=Run all unit tests. BUG=none Review URL: http://codereview.chromium.org/519070 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35705 0039d316-1c4b-4281-b951-d872f2087c98
* Speculative fix for a ChromeFrame crasher reported by go/crash. The crash ↵ananta@chromium.org2010-01-052-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | occurs while tearing down the ChromeFrameAutomationClient instance, which only gets called from the destructor of the ChromeFramePlugin class which is a base class of the ChromeFrame ActiveX. When this executes the worker thread which is used for handling urlmon requests has been destroyed. The crash occurs in the UrlmonUrlRequest::Stop function while posting a task back to an invalid message loop. We already clean up the requests in the WM_DESTROY handler, meaning that there seems to be a scenario where we don't receive a WM_DESTROY. It is unclear what that is. The fix is to call Uninitialize on the ChromeFramePlugin object in the destructor of the ActiveX which ensures that it executes while the thread is still valid. Added checks for the message loop in the relevant functions in the UrlmonUrlRequest class. Fixes bug http://code.google.com/p/chromium/issues/detail?id=31557 Bug=31557 Review URL: http://codereview.chromium.org/518034 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35561 0039d316-1c4b-4281-b951-d872f2087c98
* Adding the WidgetModeFF_CFInstanceSingleton ChromeFrame test to the list of ↵ananta@chromium.org2010-01-051-1/+3
| | | | | | | | | | | flaky tests. TBR=amit Bug=31532 Review URL: http://codereview.chromium.org/524035 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35544 0039d316-1c4b-4281-b951-d872f2087c98
* Some Chrome Frame cleanup:robertshield@chromium.org2010-01-0520-257/+173
| | | | | | | | | | | | | | | | | | 1) Rearrange the chrome_frame.gyp file to: a) Split out most of CF into a static lib to make writing unit tests easier (not having to re-include source files). b) Remove most of the un-needed xulrunner-sdk includes. 2) Move all OBJECT_ENTRY_AUTO macros to chrome_tab.cc since they don't work without extra work when residing in a lib. 3) Rename npchrome_tab.dll to npchrome_frame.dll. BUG=none TEST=none Review URL: http://codereview.chromium.org/523040 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35543 0039d316-1c4b-4281-b951-d872f2087c98
* Marking the WidgetModeFF_CFInstanceRPC and WidgetModeFF_CFInstancePost tests ↵ananta@chromium.org2010-01-041-2/+6
| | | | | | | | | | | as flaky. Bug=31532 TBR=amit Review URL: http://codereview.chromium.org/525007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35468 0039d316-1c4b-4281-b951-d872f2087c98
* Links opened in ChromeFrame via the Open in New window operation would not ↵ananta@chromium.org2010-01-042-4/+237
| | | | | | | | | | | | | | | | | | | | | render if the target also was rendered in ChromeFrame. This was because we were not marshaling the IMoniker and IBindCtx interfaces over to the ChromeFrame worker thread. The problem would only occur when we reused the existing IMoniker. Fixes bug http://code.google.com/p/chromium/issues/detail?id=30013 We need to post the OnWorkerStop message after we finish stopping the urlmon request object to prevent a race condition. We also need to pump messages in OnDestroy to ensure that CoUninitialize and calls like IBinding::Abort which callback into this thread complete correctly. Bug=30013 Review URL: http://codereview.chromium.org/523018 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35466 0039d316-1c4b-4281-b951-d872f2087c98
* The function to check whether the page is running in Chrome was incorrectly ↵ananta@chromium.org2010-01-021-0/+3
| | | | | | | | | | | | | | | | | flagging pages running in IE as running in Chrome. This was because the function was checking for the presence of the string chrome in the user agent. In ChromeFrame with host networking enabled the IE user agent contains the string chromeframe, which causes this function to fail. This caused the chromeframe unit tests to fail randomly on my machine. TBR=slightlyoff Review URL: http://codereview.chromium.org/519027 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35439 0039d316-1c4b-4281-b951-d872f2087c98
* Disabling the URLRequestTestHTTP.GetTest_NoCache test for ChromeFrame as ↵ananta@chromium.org2009-12-301-0/+4
| | | | | | | | | | | | this has been consistently failing on the chrome frame builder. TBR=tommi Review URL: http://codereview.chromium.org/515071 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35395 0039d316-1c4b-4281-b951-d872f2087c98
* Authorization headers set using XHR with ChromeFrame were stripped in the ↵ananta@chromium.org2009-12-283-1/+70
| | | | | | | | | | | | | | | | | | | outgoing HTTP requests sent via the host network stack. Fix is to remove the authorization header from the list of filtered headers. Added a unit test for this. Fixes bug http://code.google.com/p/chromium/issues/detail?id=23103 Bug=23103 Test=Covered by unit test. Review URL: http://codereview.chromium.org/519013 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35319 0039d316-1c4b-4281-b951-d872f2087c98
* Speculative fix for a ChromeFrame crash in IE full tab mode. The crash ↵ananta@chromium.org2009-12-282-3/+6
| | | | | | | | | | | | | | | | | | occurs while processing an accelerator message and based on the callstack it looks like QueryService call for the SID_STopLevelBrowser interface returns S_OK with a NULL interface pointer. Added checks in the DoQueryService helper function to return a failure if the QueryService call returns a NULL service pointer. Fixes http://code.google.com/p/chromium/issues/detail?id=25457 Bug=25457 Review URL: http://codereview.chromium.org/523008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35315 0039d316-1c4b-4281-b951-d872f2087c98
* Temporarily disable the HTML renderer type detection in our ↵ananta@chromium.org2009-12-231-2/+0
| | | | | | | | | | | | IInternerProtocolSink::ReportProgress implementation as this causes the chrome frame tests to break. TBR=stoyan Review URL: http://codereview.chromium.org/515022 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35244 0039d316-1c4b-4281-b951-d872f2087c98
* Fix ChromeFrame net tests broken by the change to determine the renderer ↵ananta@chromium.org2009-12-232-1/+15
| | | | | | | | | | | | | | | | | type in our IInternetProtocolSink::ReportProgress implementation. To determine the renderer type we try to read the data from the IInternetProtocol interface which in turn tries to determine the renderer type. Fix is to check if we are in the context of determining the renderer and bail. TBR=stoyan Bug=31031 Review URL: http://codereview.chromium.org/518012 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35234 0039d316-1c4b-4281-b951-d872f2087c98
* ChromeFrame in IE full tab mode would not render pages if Adblock Pro was ↵ananta@chromium.org2009-12-232-29/+58
| | | | | | | | | | | | | | | | | | | | | installed on the machine. Based on my debugging it looks like AdBlock gets confused because we report the mime type initally as text/html and then swich to application/chromepage. Fix is to attempt to determine the mime type in our IInternetProtocolSink::ReportProgress implementation. If we fail we continue to determine the mime type in IInternetProtocolSink::ReportData. Added a helper function CheckAndReportChromeMimeTypeForRequest which is invoked from both places. Fixes http://code.google.com/p/chromium/issues/detail?id=31031 Bug=31031 Review URL: http://codereview.chromium.org/501181 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35227 0039d316-1c4b-4281-b951-d872f2087c98
* Enable UMA data upload in ChromeFramejar@chromium.org2009-12-231-6/+0
| | | | | | | | BUG=30508 r=ananta Review URL: http://codereview.chromium.org/502019 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35223 0039d316-1c4b-4281-b951-d872f2087c98
* Refactoring build configurations - make it clearer and allow better support ↵gregoryd@google.com2009-12-221-1/+1
| | | | | | | | | | | | | for x64 on Windows TEST=none BUG=29467 Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=35012 Review URL: http://codereview.chromium.org/501127 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35129 0039d316-1c4b-4281-b951-d872f2087c98
* The ChromeFrame unit tests which use gmock exit with unexpected mock calls ↵ananta@chromium.org2009-12-212-4/+10
| | | | | | | | | | | | | warnings, which seem to be harmless at this point. Updated the relevant tests to expect these calls and ignore them. The changes to chrome_frame_automation_mock.cc are based on the review comments to the previous CL from phajdan. Review URL: http://codereview.chromium.org/504078 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35115 0039d316-1c4b-4281-b951-d872f2087c98
* The ChromeFrameAutomationClient::InitiateNavigation method saves the passed ↵ananta@chromium.org2009-12-211-5/+6
| | | | | | | | | | | | in url to its member even if it disallows the navigation. Fixed. Review URL: http://codereview.chromium.org/501128 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35113 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 35012 - Rearrange build configurations make it clearer and allow ↵gregoryd@google.com2009-12-191-1/+1
| | | | | | | | | | | | | | better support for x64 on Windows TEST=none BUG=29467 Review URL: http://codereview.chromium.org/501127 TBR=gregoryd@google.com Review URL: http://codereview.chromium.org/500149 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35016 0039d316-1c4b-4281-b951-d872f2087c98
* Rearrange build configurations - make it clearer and allow better support ↵gregoryd@google.com2009-12-191-1/+1
| | | | | | | | | | | for x64 on Windows TEST=none BUG=29467 Review URL: http://codereview.chromium.org/501127 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35012 0039d316-1c4b-4281-b951-d872f2087c98
* Fix ChromeFrame test failures on the builder caused by my CL to change the ↵ananta@chromium.org2009-12-183-19/+28
| | | | | | | | | | | | | | | | | | way the automation launch parameters are propagated to the ChromeFrameAutomationClient object. I also fixed the ChromeFrame automation mock tests which don't use gmock and instead relied on an incorrect behavior in ChromeFrame where we would deny the navigation from the automation client and still navigate in Chrome when the external tab is created. Will work on changing these tests to gmock in a subsequent CL. TBR=stoyan and thanks to him for helping debug the gmock failures. Review URL: http://codereview.chromium.org/500143 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34996 0039d316-1c4b-4281-b951-d872f2087c98
* Multiple chrome frame activex controls should instantiate and navigate ↵ananta@chromium.org2009-12-185-45/+188
| | | | | | | | | | | | | | | | | | | | | | | correctly in IE. This was not the case due to a race condition between put_src getting called for subsequent activex instances and the external tab to hold the chrome frame instance getting created. Fix is to pass in the URL if we have it when the automation client is initialized to launch the chrome automation server. If not we navigate when the external tab is created. To achieve this we stuff in all relevant parameters into a structure which is populated when the automation client is initialized. I also changed the CreateExternalTab message to carry the referrer for the initial navigation. Fixes http://code.google.com/p/chromium/issues/detail?id=28236 Test=added unit tests for the same. The firefox one is not working at this point. Disabled this test for now while I debug it. Bug=28236 Review URL: http://codereview.chromium.org/500123 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34985 0039d316-1c4b-4281-b951-d872f2087c98
* Handle right-click->"Save Link As" in the host browser.tommi@chromium.org2009-12-1610-14/+56
| | | | | | | | | TEST=Right click on a link in CF and select "save link as". You should immediately get the host browser's download UI. Before there could be a significant wait before this happened. BUG=23561 Review URL: http://codereview.chromium.org/506042 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34783 0039d316-1c4b-4281-b951-d872f2087c98
* Marking flaky test flaky.slightlyoff@chromium.org2009-12-161-1/+2
| | | | | | | | | | TBR=ananta BUG=30622 TEST=None Review URL: http://codereview.chromium.org/502040 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34774 0039d316-1c4b-4281-b951-d872f2087c98
* Tommi, please review everything. jam please review changes to ↵ananta@chromium.org2009-12-162-0/+63
| | | | | | | | | | | | | | | | | | | | | | resource_dispatcher_host.cc XMLHttpRequests issued by ChromeFrame instances would not use the host network stack at times. HTTP requests issued by these chrome instances are sent over automation to the host browser. This relies on the request having a renderer process id and a routing id for us to be able to intercept these requests. XHR requests are sent over to the browser via the ViewHostMsg_SyncLoad. This message has the routing id. However we always passed 0 down to the ResourceDispatcherHost::BeginRequest function which caused this to fail. Added a chrome frame specific unit test for this. Fixes bug http://code.google.com/p/chromium/issues/detail?id=30355 Bug=30355 Review URL: http://codereview.chromium.org/501040 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34750 0039d316-1c4b-4281-b951-d872f2087c98
* Minor change to less confusing variable name in IsSubFrameRequest in ↵robertshield@chromium.org2009-12-161-4/+4
| | | | | | | | | | ChromeFrame utils. TBR=tommi Review URL: http://codereview.chromium.org/474001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34737 0039d316-1c4b-4281-b951-d872f2087c98
* The chrome_frame_unittests firefox unit tests have been randomly failing on ↵ananta@chromium.org2009-12-151-1/+4
| | | | | | | | | | | | | | the builder due to Firefox crashing in our npapi plugin while sending out a message via the host network stack. Based on the callstack it appears that the automation client is NULL. This is a purely speculative fix to get the builder green again. TBR=stoyan Review URL: http://codereview.chromium.org/503021 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34622 0039d316-1c4b-4281-b951-d872f2087c98
* HTTPs sessions don't get established at times in ChromeFrame IE full tab ↵ananta@chromium.org2009-12-141-0/+18
| | | | | | | | | | | | | | | | | | | | | | mode. This typically happens when the initial logon redirects to an intermediate page which we try and abort in IE to ensure that Chrome follows the redirect. We try and abort the redirect in IE by returning E_ABORT from our IBindStatusCallback::OnProgress implementation and also aborting the binding. However at times urlmon continues to follow the redirect and attempts to establish a connection to the redirected url. Fix is to check for a NULL binding in our IHttpNegotiate::BeginningTransaction implementation and abort the same. Added traces in BeginningTransaction to indicate the same. Bug=30203 Test=As described in the bug. Review URL: http://codereview.chromium.org/487034 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34467 0039d316-1c4b-4281-b951-d872f2087c98
* Fix a stupid bug introduced by my previous change to fix the chrome frame ↵ananta@chromium.org2009-12-121-2/+3
| | | | | | | | | | | | | network tests, which causes the HTTP post redirect test to fail. TBR=tommi Bug=30118 Review URL: http://codereview.chromium.org/494007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34414 0039d316-1c4b-4281-b951-d872f2087c98
* The ChromeFrame redirect network tests don't complete at times as we receive ↵ananta@chromium.org2009-12-121-2/+4
| | | | | | | | | | | | | | | invalid redirect response codes in our bind status callback implementation. Fix is to default to 302 in this case. This is an attempt to get the network tests up on the builder. TBR=tommi Bug=30118 Review URL: http://codereview.chromium.org/494006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34405 0039d316-1c4b-4281-b951-d872f2087c98
* ChromeFrame's host network stack implementation for IE should ensure that ↵ananta@chromium.org2009-12-121-2/+14
| | | | | | | | | | | | | | | | | | HTTP requests issued by Chrome which terminate without any data complete correctly, i.e. we send over the request end notification to Chrome. This ensures that Chrome does not wait forever for the request to complete. This fixes http://code.google.com/p/chromium/issues/detail?id=30149, which shows up on certain sites where the throbber continues to spin at times and at times pages show up blank. Bug=30149 Test=Launch ChromeFrame in IE and navigate to cf:http://www.tennisballcricket.org. We should not see a blank page. Will look into a unit test for this. Review URL: http://codereview.chromium.org/491057 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34400 0039d316-1c4b-4281-b951-d872f2087c98
* Use the OnHttpEquiv notification to switch to CF when the http-equiv meta ↵tommi@chromium.org2009-12-118-204/+210
| | | | | | | | | | | | | | | | tag is detected. This implementation is still behind the registry switch (set PatchProtocols to 0 in the registry). I will switch over to it wholesale in a separate patch. We use the same mechanism for re-initiating the navigation we use to transfer downloads over to the host, so I moved the common code to utils.cc and added NavigateBrowserToMoniker. When we see a browser instance attempting to load a CF document, we raise a TLS flag that we catch in HttpNegotiatePatch::ReportProgress when the mime type is being reported. This is the same place where we examine http headers and report the mime type. BUG=n/a TEST=Set PatchProtocols (REG_DWORD) to 0 in the CF HKCU config key and make sure we detect and handle the meta tag as well or better than before. Review URL: http://codereview.chromium.org/489004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34366 0039d316-1c4b-4281-b951-d872f2087c98
* The ChromeFrame net tests randomly crash in the url request redirect tests ↵ananta@chromium.org2009-12-111-0/+7
| | | | | | | | | | | | | | | | | | | | | | on the chrome frame builder. Some debugging revealed that we send over two redirect responses from the IE host network stack implementation to Chrome, which causes a crash in the url request automation job while dereferencing a NULL request. Two redirect responses are sent in the following scenario:- 1. We received a redirect notification in our bind status callback. We abort the binding and return E_ABORT. 2. Eventually we receive a call in our bind status callback implementation of OnResponse even after the binding was aborted. This causes the response to be sent twice. Added a check for a NULL binding and a trace in the IE host network stack implementation. I also added a NOTREACHED in the url request automation job if we ever receive a message for an automation job which has a NULL request. Bug=30118 Review URL: http://codereview.chromium.org/487028 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34360 0039d316-1c4b-4281-b951-d872f2087c98