summaryrefslogtreecommitdiffstats
path: root/chrome_frame/urlmon_url_request.h
Commit message (Collapse)AuthorAgeFilesLines
* Nicely steal moniker and bind context from the urlmon url request.stoyan@chromium.org2010-04-281-0/+5
| | | | | | | 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
* Handle cookie requests in BackgroundThread.stoyan@chromium.org2010-04-201-0/+2
| | | | | | | | | 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
* Fix for remaining major issues with moniker patchamit@chromium.org2010-04-141-24/+1
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Preparation CL for executing READ and COOKIE network requests from the ↵stoyan@chromium.org2010-04-131-6/+6
| | | | | | | | 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
* Move Urlmon network requests to UI thread, thus allowing reusing the bind ↵stoyan@chromium.org2010-04-081-43/+30
| | | | | | | | | | | | | 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
* Fix a crash whereby a non-thread-safe ref-counted net::UploadData is used ↵robertshield@chromium.org2010-03-311-2/+2
| | | | | | | | | | | 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
* Reenable the ChromeFrame unload event test which basically loads a page ↵ananta@chromium.org2010-03-261-0/+5
| | | | | | | | | | | | | | | | | | | | | 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
* Fix for a race issue when chrome decides that a request needs to be ↵tommi@chromium.org2010-03-251-6/+6
| | | | | | | | | | | | | | 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
* When ChromeFrame is running in privileged mode, we should fail the ↵ananta@chromium.org2010-03-221-0/+8
| | | | | | | | | | | | | 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
* Initial support for IE View->Privacy. To support this menu option the active ↵ananta@chromium.org2010-03-191-2/+40
| | | | | | | | | | | | | | | | | | | | | | | 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
* Fix #1 for multiple request issue (both POST and GET) after activating the ↵tommi@chromium.org2010-03-121-14/+27
| | | | | | | | | | | | | | | | | | | | | 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
* ChromeFrame should honor the host browser's cookie policy. To achieve this ↵ananta@chromium.org2010-03-021-5/+4
| | | | | | | | | | | | | | | | 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
* Provide parent window for Urlmon error dialogs.stoyan@chromium.org2010-02-041-1/+2
| | | | | | Review URL: http://codereview.chromium.org/567036 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@38053 0039d316-1c4b-4281-b951-d872f2087c98
* Renabling the FullTabModeIE_ChromeFrameUnloadEventTest ChromeFrame test. ↵ananta@chromium.org2010-02-031-1/+4
| | | | | | | | | | | | | | | | | | | | | | | 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
* Bring the lock in UrlmonUrlRequestManager back. We need it to access worker ↵stoyan@chromium.org2010-02-021-0/+4
| | | | | | | | | | 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
* TEST=new tests added.stoyan@chromium.org2010-02-011-247/+61
| | | | | | Review URL: http://codereview.chromium.org/545093 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@37728 0039d316-1c4b-4281-b951-d872f2087c98
* The cache object used by the UrlmonUrlRequest class in ChromeFrame creates ↵ananta@chromium.org2009-12-081-8/+6
| | | | | | | | | | | | | | | | | | | | 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
* Fix a crash caused by a race condition between the time the ↵ananta@chromium.org2009-12-021-0/+5
| | | | | | | | | | | | | | | | | | 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
* Transfer CF downloads to the host browser.TEST=Click a download link (not ↵tommi@chromium.org2009-11-251-0/+2
| | | | | | | | 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
* ChromeFrame's host network stack implementation for IE full tab mode ↵ananta@chromium.org2009-11-241-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | 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
* The ChromeFrameAutomationClient class needs to be refcounted as it ↵ananta@chromium.org2009-11-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | 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
* ChromeFrame HTTP requests would randomly fail if we navigated to multiple ↵ananta@chromium.org2009-11-111-6/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Using thread safe reference counting to wrap the UploadData instance.Moving ↵tommi@chromium.org2009-10-291-2/+0
| | | | | | | | 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
* Currently the host network stack in IE which uses Urlmon interfaces to initiateananta@chromium.org2009-10-241-2/+29
| | | | | | | | | | | | | | | | | | | | | 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
* Initial import of the Chrome Frame codebase. Integration in chrome.gyp ↵slightlyoff@chromium.org2009-09-241-0/+231
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