summaryrefslogtreecommitdiffstats
path: root/chrome_frame/chrome_frame_automation.cc
Commit message (Collapse)AuthorAgeFilesLines
* Enable UMA data upload in ChromeFramejar@chromium.org2009-12-231-6/+0
| | | | | | | | BUG=30508 r=ananta Review URL: http://codereview.chromium.org/502019 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35223 0039d316-1c4b-4281-b951-d872f2087c98
* The ChromeFrameAutomationClient::InitiateNavigation method saves the passed ↵ananta@chromium.org2009-12-211-5/+6
| | | | | | | | | | | | in url to its member even if it disallows the navigation. Fixed. Review URL: http://codereview.chromium.org/501128 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35113 0039d316-1c4b-4281-b951-d872f2087c98
* Multiple chrome frame activex controls should instantiate and navigate ↵ananta@chromium.org2009-12-181-28/+45
| | | | | | | | | | | | | | | | | | | | | | | 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 chrome_frame_unittests firefox unit tests have been randomly failing on ↵ananta@chromium.org2009-12-151-1/+4
| | | | | | | | | | | | | | the builder due to Firefox crashing in our npapi plugin while sending out a message via the host network stack. Based on the callstack it appears that the automation client is NULL. This is a purely speculative fix to get the builder green again. TBR=stoyan Review URL: http://codereview.chromium.org/503021 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34622 0039d316-1c4b-4281-b951-d872f2087c98
* Back/Forward support for url fragmentsamit@chromium.org2009-11-191-2/+1
| | | | | | | | | | | | | | | | | Added support for anchor (url fragments). this involves mainly implementing IPersistHistory. The rest of the stuff is a song and dance to get called in IPersistHistory in the first place and then behave correctly when we do. BUG=23981 TEst=unit tests added and back forward with '#' URLs, sub frames etc. Review URL: http://codereview.chromium.org/371004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32454 0039d316-1c4b-4281-b951-d872f2087c98
* The ChromeFrameAutomationClient class needs to be refcounted as it ↵ananta@chromium.org2009-11-121-18/+8
| | | | | | | | | | | | | | | | | | | | | | 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
* This CL fixes the following issues:-ananta@chromium.org2009-11-111-7/+19
| | | | | | | | | | | | | | | | | | | | | | | 1. http://code.google.com/p/chromium/issues/detail?id=27200 This was a crash which would occur in the Stop function in the UrlmonUrlRequest object which would get invoked when the active document instance was being destroyed. The crash occured if the active document instance was reused in which case we end up reusing the automation client instance. The fix is to ensure that we clean up existing requests from the map before reusing the automation client instance. 2. http://code.google.com/p/chromium/issues/detail?id=27202 This was a DCHECK which would occur when adding a new request to the request map, which indicated that an existing request with the same request id existed in the map. This would occur during a redirect where the request id is reused by Chrome. Fix is to remove the request from the map when we handle the AutomationMsg_RequestEnd message in the UI thread itself. The UrlmonUrlRequest functions which attempt to remove the request from the map now check if the request is valid before doing this. Bug=27200,27202 Review URL: http://codereview.chromium.org/388008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31681 0039d316-1c4b-4281-b951-d872f2087c98
* Modifying extension automation so that it is done through a particularjoi@chromium.org2009-11-081-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | 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-6/+20
| | | | | | | | 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
* Continue to remove CHROME_FRAME_BUILD define from code that goes into ↵robertshield@chromium.org2009-11-041-2/+7
| | | | | | | | | | | | | | | | | | | | | chrome.dll. This reworks the browser distribution code to use the ChromeFrameBrowserDistribution iff --chrome-frame is present on the command line. Also, * At startup, chrome.exe now uses the BrowserDistribution code to determine where the Chromium version key resides (instead of hard coding it). * The installer now propagates the presence of --verbose-logging to uninstalls. * The chrome_launcher now allows the --chrome-frame switch through to chrome. * The installer now accepts a --chrome-frame switch. * Remove almost all occurences of the CHROME_FRAME_BUILD define from the installer. BUG=26012, 26603 TEST=Chrome Frame still builds and runs correctly. Chrome Frame builds built without 'branding'='Chrome' now install correctly. Review URL: http://codereview.chromium.org/345021 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31015 0039d316-1c4b-4281-b951-d872f2087c98
* Using thread safe reference counting to wrap the UploadData instance.Moving ↵tommi@chromium.org2009-10-291-1/+1
| | | | | | | | 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
* Remove a DCHECK that happens on every exit of IE. We appear to be leaking ↵robertshield@chromium.org2009-10-281-1/+6
| | | | | | | | | | automation proxies, which I maintain is a bad thing. BUG=Start IE with debug CF installed, navigate to a chrome frame page, exit IE, see the DCHECK. Review URL: http://codereview.chromium.org/342018 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@30366 0039d316-1c4b-4281-b951-d872f2087c98
* Remove the Chrome Frame preprocessor define in chrome_constants.cc and deal ↵robertshield@chromium.org2009-10-281-4/+5
| | | | | | | | | | | | with resulting fallout. Also, remove several instances of Chrome Frame using wstrings instead of FilePaths. The main goal of this patch is to move towards ensuring that Chrome Frame and Google Chrome share binary-identical exes and dlls except for setup.exe and mini_installer.exe. Review URL: http://codereview.chromium.org/338025 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@30290 0039d316-1c4b-4281-b951-d872f2087c98
* If a HTTP post to a server returns any redirect code other than 307, then ↵ananta@chromium.org2009-10-271-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Hopefully the last of the fixes to get Chrome Frame tests going again.ananta@chromium.org2009-10-241-0/+15
| | | | | | | | | | | | | | | | 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
* Attempts to get the chrome_frame_tests going again on the chrome frame ↵ananta@chromium.org2009-10-241-1/+0
| | | | | | | | | | | | | | | | | | | | | | builder. Fixes as below:- 1. Removed a DCHECK from ChromeFrameAutomationClient::CleanupRequests which checks if the request was actually deleted. This DCHECK is not correct anymore as the request is stopped asynchronously. 2. We now stop the worker thread in WM_DESTROY as the activex window needs to be valid for Urlmon requests to be released correctly. In some cases IE reuses the ActiveX instance. So we need to create the worker thread on demand. TBR=amit Review URL: http://codereview.chromium.org/334020 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@30007 0039d316-1c4b-4281-b951-d872f2087c98
* Currently the host network stack in IE which uses Urlmon interfaces to initiateananta@chromium.org2009-10-241-1/+1
| | | | | | | | | | | | | | | | | | | | | 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-2/+2
| | | | | | | | | | | | | | 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/+87
| | | | | | | | | 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
* Assigning INFINITE (which is 0xFFFFFFFF) to an int, is not a very good idea...mad@chromium.org2009-10-191-4/+8
| | | | | | | | | BUG=none TEST=none Review URL: http://codereview.chromium.org/285012 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@29478 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-5/+7
| | | | | | | | | | | | | | | | | | | | | | | 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
* Fixing a tiny bit of silliness in chrome_frame_automation.cc.robertshield@chromium.org2009-10-151-2/+1
| | | | | | Review URL: http://codereview.chromium.org/271097 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@29114 0039d316-1c4b-4281-b951-d872f2087c98
* Turn off Chrome error dialogs when it is launched by Chrome Frame.robertshield@chromium.org2009-10-071-0/+4
| | | | | | Review URL: http://codereview.chromium.org/260018 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@28264 0039d316-1c4b-4281-b951-d872f2087c98
* Added support for specifying the BrowserFlags DWORD value when we register ↵ananta@chromium.org2009-10-061-0/+13
| | | | | | | | | | | | | | | | | | | | | | 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
* Pass the renderer a11y flag to Chrome Frame-created renderers.slightlyoff@chromium.org2009-10-061-0/+2
| | | | | | | | | BUG=23669 TEST=watch event32 a11y event log on pages which render in GCF. Review URL: http://codereview.chromium.org/255062 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@28081 0039d316-1c4b-4281-b951-d872f2087c98
* Committing patch 256001 for Roger:http://codereview.chromium.org/256001Allow ↵tommi@chromium.org2009-10-011-3/+5
| | | | | | | | 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
* Reverting 27389.darin@chromium.org2009-09-301-2/+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/+2
| | | | | | | | 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-2/+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
* Validate URLs being navigated to by ChromeFrame in the ↵ananta@chromium.org2009-09-251-4/+7
| | | | | | | | | | | | | | ChromeFrameAutomationClient::InitiateNavigation method as this is a central chokepoint. Should fix http://b/issue?id=1934996 Bug=1934996 Review URL: http://codereview.chromium.org/235017 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27273 0039d316-1c4b-4281-b951-d872f2087c98
* Initial import of the Chrome Frame codebase. Integration in chrome.gyp ↵slightlyoff@chromium.org2009-09-241-0/+975
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-03-03 04:35:24 +0000