summaryrefslogtreecommitdiffstats
path: root/chrome_frame/chrome_frame_delegate.h
Commit message (Collapse)AuthorAgeFilesLines
* Added the propagation of the OnChannelError notification.mad@chromium.org2010-03-261-3/+7
| | | | | | | | | | | So that automation tests can tell when the communication between Chrome and Chrome Frame was cut. BUG=none TEST=none Review URL: http://codereview.chromium.org/1237003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42810 0039d316-1c4b-4281-b951-d872f2087c98
* Don't access front() if the queue is empty.tommi@chromium.org2010-03-191-1/+1
| | | | | | | | | TEST=This fixes a crash that I ran into when testing CF. I was using this page: http://testbed.nicon.nl/googlechrome/testcase_googlechrome.asp?cnt=plus BUG=38547 Review URL: http://codereview.chromium.org/1107005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42054 0039d316-1c4b-4281-b951-d872f2087c98
* Adds an automation message to retrieve the list of enabled extensions, and ↵joi@chromium.org2010-03-161-0/+7
| | | | | | | | | | | CF bindings for it. TEST=unit test to follow BUG=none Review URL: http://codereview.chromium.org/901002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@41667 0039d316-1c4b-4281-b951-d872f2087c98
* AddRef ChromeFrameAutomationClient as long as the supporting window exists.stoyan@chromium.org2010-03-111-7/+15
| | | | | | | | | | | | Crash was due the final Release() called from inside message handler. Additionally prevent invoking member functions of invalid/old chrome_frame_delegate_. Still have a race acessing url_fetcher_ though. BUG=35556 Review URL: http://codereview.chromium.org/825005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@41290 0039d316-1c4b-4281-b951-d872f2087c98
* ChromeFrame now uses host provided popup blocker.stoyan@chromium.org2010-03-081-2/+2
| | | | | | | | | | | It does not work in all scenarions since from Chrome side an empty string is passed as target url. Note in IE6 "Tools/Popup Blocker" menu is not visible if ChromeFrame is the activedocument. Have to support some IOleCommandTarget command.. BUG=34823 Review URL: http://codereview.chromium.org/668168 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@40897 0039d316-1c4b-4281-b951-d872f2087c98
* ChromeFrame should honor the host browser's cookie policy. To achieve this ↵ananta@chromium.org2010-03-021-0/+3
| | | | | | | | | | | | | | | | 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
* Revert "Fix the case where the browser livelocks if we cannot open a file."agl@chromium.org2010-03-011-0/+37
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@40291 0039d316-1c4b-4281-b951-d872f2087c98
* Fix the case where the browser livelocks if we cannot open a file.agl@chromium.org2010-02-261-37/+0
| | | | | | | | | | | | | | | | | | | | If one tries to upload a file that one doesn't have read access to, the browser livelocks. It tries to read from the file, gets nothing but spins forever because it knows that it hasn't finished reading. To address this, firstly we add a check at stat() time to make sure that we can read the file. However, this doesn't take care of the case where the access() call was incorrect, or the permissions have changed under us. In this case, we replace the missing file with NULs. (Land attempt three: first in r39446, reverted in r39448. Second in r39899, reverted in r39901.) http://codereview.chromium.org/541022 BUG=30850 TEST=Try to upload a file that isn't readable (i.e. /etc/shadow). The resulting upload should be a 0 byte file. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@40146 0039d316-1c4b-4281-b951-d872f2087c98
* Destroy pending tasks marshaled through windows messages avoiding possible ↵stoyan@chromium.org2010-02-261-0/+37
| | | | | | | | | | | crashes when object is destroyed and there is tasks in the queue. BUG=none TEST=none Review URL: http://codereview.chromium.org/661145 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@40125 0039d316-1c4b-4281-b951-d872f2087c98
* Clone of issue 600130. (http://codereview.chromium.org/600130)twiz@chromium.org2010-02-161-0/+6
| | | | | | | | | BUG=None TEST=None Review URL: http://codereview.chromium.org/593111 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@39077 0039d316-1c4b-4281-b951-d872f2087c98
* Handle right-click->"Save Link As" in the host browser.tommi@chromium.org2009-12-161-1/+2
| | | | | | | | | 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
* Basic wiring to enable downloads for CF's host browser network stack. A ↵tommi@chromium.org2009-11-071-0/+1
| | | | | | | | notable change here is that url automation job id's no longer exist and instead a request id is used. There's a 1 to 1 relation between a job and a request so this is more convenient. Review URL: http://codereview.chromium.org/355036 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31363 0039d316-1c4b-4281-b951-d872f2087c98
* Currently the host network stack in IE which uses Urlmon interfaces to initiateananta@chromium.org2009-10-241-1/+44
| | | | | | | | | | | | | | | | | | | | | 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
* Add bindings to chrome frame to call the new extension automation apis.rogerta@chromium.org2009-10-231-0/+9
| | | | | | | | | TEST=see unit tests BUG=0 Review URL: http://codereview.chromium.org/284017 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@29902 0039d316-1c4b-4281-b951-d872f2087c98
* When Chrome hands off a URL to be opened by the external host by the ↵ananta@chromium.org2009-10-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | ViewHostMsg_OpenURL IPC, it needs to pass the referrer as well. The Chrome fixes in this CL are mostly related to passing the HTTP referer off to the browser and from there to the ExternalTabContainer to ChromeFrame and back. The ChromeFrame changes are basically around the same lines with one exception. When we handle the AutomationMsg_OpenURL IPC in the activex and the active document we pass the referer if applicable to the WebBrowser2::Navigate2 interface, which is then read by the BHO in BeforeNavigate2. We then save away an AddRef'ed BHO pointer in TLS which is then referenced by the Active document for reading the referer and passing it off to Chrome in the NavigateInExternalTab message. Added a unit test in ChromeFrame which tests this case. This fixes http://code.google.com/p/chromium/issues/detail?id=22994 Bug=22994 Review URL: http://codereview.chromium.org/274071 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@29420 0039d316-1c4b-4281-b951-d872f2087c98
* This CL is for the needs of ChromeFrame.stoyan@google.com2009-10-131-0/+1
| | | | | | | | | | | | TabContentsDelegate implementation may override navigations caused by JsvaScript history object. Yet not perfect since webkit view of navigation stack differs from the view of external-non-Chrome-host-browser. We have to provide the full stack from host-browser (+visited links alongside) in the same way as Chrome-browser provides it to renderer. BUG=24004 Review URL: http://codereview.chromium.org/261046 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@28818 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting 27389.darin@chromium.org2009-09-301-5/+2
| | | | | | Review URL: http://codereview.chromium.org/246027 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27594 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting 27379, in hopes of fixing browser_tests.senorblanco@chromium.org2009-09-281-2/+5
| | | | | | | | TBR=darin Review URL: http://codereview.chromium.org/248021 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27389 0039d316-1c4b-4281-b951-d872f2087c98
* Assert that thread-safe reference counting is used withdarin@chromium.org2009-09-281-5/+2
| | | | | | | | | | | | | | | | | | | | | | | | cross-thread NewRunnableMethod. This assertion caught such an error in VisitedLinkMaster! My approach, modify RunnableMethodTraits<T> to assert that when ReleaseCallee happens on a different thread from RetainCallee that the type supports thread-safe reference counting. I do this by adding a static method to both RefCounted<T> and RefCountedThreadSafe<T>. This results in a little ugliness in cases where people implement AddRef and Release by hand (to make the no-ops). There may be a nicer way to deal with those few cases. R=brettw BUG=none TEST=none Review URL: http://codereview.chromium.org/251012 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27379 0039d316-1c4b-4281-b951-d872f2087c98
* Initial import of the Chrome Frame codebase. Integration in chrome.gyp ↵slightlyoff@chromium.org2009-09-241-0/+99
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
generated by cgit v1.1 at 2025-01-17 23:37:22 +0000