| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
tests on the builder.
TBR=robertshield
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36010 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|