| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/545093
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@37728 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
implements the PluginRequestHandler
interface which is maintained by individual requests which can outlive the active document/activex instances.
I ran into a crash where UrlmonUrlRequest was calling into an invalid PluginRequestHandler pointer which
had been destroyed just before.
We also need to ensure that UrlmonUrlRequest and ChromeFrameActiveXBase select the multi threaded model as
AddRef/Release can be invoked from multiple threads.
I also removed the CleanupAsyncRequests function in ChromeFrameAutomationClient and moved all the code to CleanupRequests, which ensures that we treat synchronous
and asynchronous requests similarly.
There are instances where an automation client instance is created and destroyed without being initialized which causes a spurious assert to fire in the Uninitialize function. I added a check in the Uninitialize function to return if the state is uninitialized.
Bug=none
Review URL: http://codereview.chromium.org/386014
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31792 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
the post_data_len_ member variable to the PluginUrlRequest class.TEST=This is a tentative fix for bug 25531.BUG=25531
Review URL: http://codereview.chromium.org/340006
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@30432 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
browsers don't preserve the
request method, i.e. they convert the POST request to GET. For 307 redirects browsers preserve redirects.
This CL fixes the following issues :-
1. As per the above description, we reset the method which
ensures that we don't generate the post related headers.
The Post302RedirectGet net test does test this very case.
However it works correctly as Chrome follows the redirect
and reissues the GET request. In this case this does not
occur as the only calls which are invoked on the bind
status callback after the redirect are GetBindInfo and
BeginningTransaction where we incorrectly return the post
related information. Ideally we would want to turn off
follow redirects in Urlmon or Chrome. I tried the latter
which has a number of issues.
2. In debug mode the chrome_frame_net_tests cause a DCHECK
to be fired which indicates that the test is not being
run on the UI thread.
3. As the Urlmon requests are now destroyed asynchronously
having a DCHECK after the Stop call on the Urlmon
request object in the CleanupAsyncRequests function is
incorrect. Removed this DCHECK
Fixes bug http://code.google.com/p/chromium/issues/detail?id=25643
Bug=25643
Review URL: http://codereview.chromium.org/333043
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@30261 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and complete URL downloads requested by ChromeFrame, executes in the UI thread of IE.
While this works fine in most cases for large data sizes, the IE UI thread ends up being
busy pulling the data in our IBindStatusCallback::OnDataAvailable implementation. As a result
the browser hangs until all data is pulled out.
The fix is to handle Urlmon requests on a separate thread.
This fixes http://code.google.com/p/chromium/issues/detail?id=24007
Changes to plugin_url_request.cc/.h are to set the LF property on these files.
Bug=24007
Review URL: http://codereview.chromium.org/292035
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@29986 0039d316-1c4b-4281-b951-d872f2087c98
|
|
coming in a separate CL.
BUG=None
TEST=None
Review URL: http://codereview.chromium.org/218019
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27042 0039d316-1c4b-4281-b951-d872f2087c98
|