summaryrefslogtreecommitdiffstats
path: root/chrome_frame/chrome_frame_automation.h
Commit message (Collapse)AuthorAgeFilesLines
* TEST=new tests added.stoyan@chromium.org2010-02-011-19/+29
| | | | | | Review URL: http://codereview.chromium.org/545093 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@37728 0039d316-1c4b-4281-b951-d872f2087c98
* Multiple chrome frame activex controls should instantiate and navigate ↵ananta@chromium.org2009-12-181-12/+23
| | | | | | | | | | | | | | | | | | | | | | | 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
* The ChromeFrameAutomationClient class needs to be refcounted as it ↵ananta@chromium.org2009-11-121-10/+0
| | | | | | | | | | | | | | | | | | | | | | 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
* Modifying extension automation so that it is done through a particularjoi@chromium.org2009-11-081-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | tab for all extension views. Previously, API routing to the automation client would only work for extension views that were contained in the particular ExternalTab instance being automated. This meant you couldn't test API calls from e.g. background pages. Also using async functions instead of the previous RVH-based hack. Updating one of the UI tests to make the API calls from a background page, to provide an end-to-end test of the new routing. This makes AutomationProvider::SetEnableAutomationExtension Windows-only, but it effectively always was since it was already dependent on ExternalTabContainer (indirectly, to provide a non-empty implementation of TabContentsDelegate::ForwardMessageToExternalHost). BUG=none TEST=ui_tests.exe, chrome_frame_tests.exe, chrome_frame_unittests.exe Review URL: http://codereview.chromium.org/366025 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31403 0039d316-1c4b-4281-b951-d872f2087c98
* Basic wiring to enable downloads for CF's host browser network stack. A ↵tommi@chromium.org2009-11-071-1/+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
* Hopefully the last of the fixes to get Chrome Frame tests going again.ananta@chromium.org2009-10-241-0/+3
| | | | | | | | | | | | | | | | 1. Added a check in the OnDestroy handler for the ChromeFrame ActiveX as to whether the worker thread is valid before posting a task to it. 2. Added a helper function in ChromeFrameAutomationClient to support asynchronous host network stack requests deletion. If this does not work I will revert the previous CL's. TBR=amit Review URL: http://codereview.chromium.org/338010 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@30010 0039d316-1c4b-4281-b951-d872f2087c98
* Currently the host network stack in IE which uses Urlmon interfaces to initiateananta@chromium.org2009-10-241-29/+7
| | | | | | | | | | | | | | | | | | | | | 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
* Enhance extension UI testing by enabling you to select which extensionjoi@chromium.org2009-10-231-4/+7
| | | | | | | | | | | | | | APIs to forward (and thus stub out in your test), while others will keep being fulfilled as per usual. This lets you build tests that stub out one piece of behavior while testing that some side effects of another API happen as expected. BUG=none TEST=Run ui_tests.exe Review URL: http://codereview.chromium.org/314015 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@29919 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
* Give ourselves 20 seconds for Chrome startup vs 4 to help alleviate ↵slightlyoff@chromium.org2009-10-211-1/+4
| | | | | | | | | | | intermittent "blank page" GCF bugs. BUG=23414 TEST=None Review URL: http://codereview.chromium.org/293035 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@29590 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-2/+4
| | | | | | | | | | | | | | | | | | | | | | | 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
* Added support for specifying the BrowserFlags DWORD value when we register ↵ananta@chromium.org2009-10-061-0/+3
| | | | | | | | | | | | | | | | | | | | | | the ChromeFrame Active Document server. This allows the document server to receive a number of menu events like Find, View->Text Size, etc. Thanks to Stoyan for helping me debug this :) Clicking on Edit->Find in the menu in IE with this causes IEFrame to call our Active document's Exec implementation with the IDM_FIND command. The handling here is to invoke our default Find handling. Added support for honoring user text size selections. The next thing to be done is to honor the current text size setting while launching Chrome. I also fixed the rgs files to have LF as the terminating character. This fixes Bug http://code.google.com/p/chromium/issues/detail?id=23667 Bug=23667 Review URL: http://codereview.chromium.org/243082 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@28085 0039d316-1c4b-4281-b951-d872f2087c98
* Committing patch 256001 for Roger:http://codereview.chromium.org/256001Allow ↵tommi@chromium.org2009-10-011-1/+1
| | | | | | | | Chrome Frame to display chrome-extension URLs when running in privilegedmode.BUG=noneTEST=see unit tests Review URL: http://codereview.chromium.org/246050 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27724 0039d316-1c4b-4281-b951-d872f2087c98
* Initial import of the Chrome Frame codebase. Integration in chrome.gyp ↵slightlyoff@chromium.org2009-09-241-0/+356
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-31 22:16:15 +0000