| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
BUG=42104
Review URL: http://codereview.chromium.org/1811001
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@45860 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
Enable the unload event test.
BUG=40814
TEST=unload event test
Review URL: http://codereview.chromium.org/1629027
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@45042 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
background thread.
Review URL: http://codereview.chromium.org/1520033
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@44369 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
context (and already fetched data) via INET_E_TERMINATED_BIND error code.
Make caching of data more sensible, so the UI does not freeze (the reason why url request have been moved to a background thread).
Always return INET_E_TERMINATED_BIND on OnDataAvailable when BSCF_LASTDATANOTIFICATION flag is detected, so if a subsequent DownloadToHost request comes from Chrome, bind context and already fetched data can be reused.
BUG=36694
Review URL: http://codereview.chromium.org/1523014
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@43953 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
between threads. This patch does this by wrapping the UploadData structure in a thread-safe container for use between threads.
BUG=39453
TEST=none
Review URL: http://codereview.chromium.org/1508012
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@43287 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
which in its unload handler sets
a cookie which the new page attempts to read. This does not work as expected in ChromeFrame as the cookie
reading and writing attempts are routed to the host browser, in this case IE which is waiting for the
WM_DESTROY message sent to the external tab to return.
Fix is to process the AutomationMsg_GetCookiesFromHost and AutomationMsg_SetCookieAsync IPC messages
in the background thread which works in IE. For Firefox they continue to be processed on the UI thread
as before.
Fixes bug http://code.google.com/p/chromium/issues/detail?id=37231
Bug=37231
Review URL: http://codereview.chromium.org/1342004
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42855 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
downloaded by the host browser.
Before the request could under some circumstances be terminated before we handed it over to the host for download.
In such cases we would just drop the request and not download anything.
TEST=Fixes flakyness of _some_ download scenarios. This is only a part of a fix needed for the related bug.
BUG=36694
Review URL: http://codereview.chromium.org/1240004
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42673 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
IAuthenticate::Authenticate method
to prevent an authentication dialog from being displayed by IE.
This CL passes this information to the Url request manager which in turn passes this to the
requests.
Review URL: http://codereview.chromium.org/1153006
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42275 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
document now implements
the Exec command for the CGID_ShellDocView group and command id 75. We invoke the DoPrivacyDlg function
exported by shdocvw and pass in our implementation of the IEnumPrivacyServices interface.
The actual privacy data is gathered and maintained by the UrlmonUrlRequestManager. If we detect a privacy
violation we notify the shell browser via the ITridentService2::FirePrivacyImpactedStateChange function
which ensures that IE displays the privacy icon.
Thanks to stoyan for his help in getting this done.
I will add tests in a followup CL.
Fixes bug http://code.google.com/p/chromium/issues/detail?id=25479
Bug=25479
Review URL: http://codereview.chromium.org/1127003
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42113 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
we always read the cookies from
the host browser when the renderer requests them. This also cleans up the mess with the host network stack
code parsing cookies from the host looking for persistent cookies.
Fixes bug http://code.google.com/p/chromium/issues/detail?id=34151
Bug=34151
Test=Covered by existing host network stack tests and chrome frame cookie tests.
Review URL: http://codereview.chromium.org/661290
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@40402 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/567036
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@38053 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This test failed at times
on the builder due to a deadlock between the urlmon worker thread in IE and the ui thread. This would
occur when the active document instance was going away while the worker thread was waiting for a COM
call to be marshaled to the UI thread which expects the thread to pump messages.
The only interface which needs to be marshaled to the worker thread is the IBindCtx interface. Turns out
that there is nothing of note in this object, except the bind options. The rest of the properties queried
for all fail initially and then the caller register its own variants of these properties.
Fix is to create a new IBindCtx interface and copy over the BIND_OPTs to this interface.
Fixes bug http://code.google.com/p/chromium/issues/detail?id=34246
Bug=34246
Review URL: http://codereview.chromium.org/566026
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@37916 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
thread's message loop.
Added the unsafe redirect handling.
Review URL: http://codereview.chromium.org/568004
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@37782 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/545093
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@37728 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
an in memory stream, which is used
to hold data received from Urlmon until Chrome reads it. At times attempts to write to this stream fail
with E_OUTOFMEMORY.
We don't really need the complexity of an in memory stream for our cache. A vector of bytes would do just fine.
This fixes bug http://code.google.com/p/chromium/issues/detail?id=28658
I verified that it actually fixes this issue.
Bug=28648
Test=covered by existing net tests.
Review URL: http://codereview.chromium.org/469014
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34086 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
UrlmonUrlRequest::EndRequestInternal task
executing and the OnStopBinding function getting called by Urlmon. If our task executes first we essentially
operate on an invalid object.
Fixes http://code.google.com/p/chromium/issues/detail?id=29033
Added a comment to the EndRequest function indicating that it is invalid to access any members after it
is called. Added a helper function to release the bindings and revoke the bind status callback.
Bug=29033
Review URL: http://codereview.chromium.org/456013
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33551 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
via redirect) in a web page displayed by Chrome Frame. The request should be handled by the host browser.BUG=23561
Review URL: http://codereview.chromium.org/385108
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33022 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
implicitly follows redirects.
When Chrome receives a notification about a redirect it also attempts to follow the redirect request. While
this works in most cases, some sites actually returned an error for the second request initiated by Chrome.
Fix is to abort the request in urlmon, when we receive a notification about a redirect. I also fixed the
IsRedirectResponse function in the UrlRequestAutomationJob class to only treat 301, 302, 303 and 307 as
redirect codes on the same lines as the default http job.
Test=covered by existing network tests.
I also verified that http://code.google.com/p/chromium/issues/detail?id=25643 works with this CL.
Fixes http://code.google.com/p/chromium/issues/detail?id=28296
Bug=28296
Review URL: http://codereview.chromium.org/402107
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32896 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
HTTP sites. This was because
the automation resource message filter tracked HTTP requests based on the request ids which are generated
by the renderer process. As a result a new request would get created say with id 0, while an existing request
would end in ChromeFrame causing the new request to incorrectly shutdown.
Fix is to revert back to the original way of tracking requests with an auto incrementing id. The automation url
job maintains both ids now, i.e. the automation request id and the chrome request id. The download notification
receives the automation id and basically looks up the associated automation request id and sends the notification
back to ChromeFrame.
This fixes bug http://code.google.com/p/chromium/issues/detail?id=27401
Other fixes in this CL include the following:-
1. The active document instance would never get destroyed. This was because we call ShowUI on the doc host
which maintains a reference. We need to call HideUI in Setsite of NULL, which releases the reference.
2. When the active x instance is shutting down we try to shutdown all running requests in the OnDestroy handler.
To ensure that the request is deleted from the request map and released in the same thread which created it
we post a task back to the ui thread which never runs as the window is being destroyed. Fix is to create
a message only window with every urlmonrequest instance which supports task marshaling.
Tests in a future CL.
Bug=27401
Review URL: http://codereview.chromium.org/386008
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31731 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|