summaryrefslogtreecommitdiffstats
path: root/chrome_frame/test/automation_client_mock.h
Commit message (Collapse)AuthorAgeFilesLines
* iwyu: Include stringprintf.h where appropriate, part 2.jhawkins@chromium.org2011-05-111-0/+1
| | | | | | | | | | | BUG=82098 TEST=none R=thakis@chromium.org Review URL: http://codereview.chromium.org/7004007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@85048 0039d316-1c4b-4281-b951-d872f2087c98
* Removing command_execution_timeout_ms in favor of action_max_timeout_ms.hnguyen@chromium.org2011-04-111-0/+4
| | | | | | | R=jcivelli@chromium.org,sky@chromium.org,phajdan.jr@chromium.org,nirnimesh@chromium.org Review URL: http://codereview.chromium.org/6685099 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@81164 0039d316-1c4b-4281-b951-d872f2087c98
* Remove extension automation support that was used only by CEEE.joi@chromium.org2011-04-061-1/+0
| | | | | | | | | BUG=none TEST=all automated tests pass Review URL: http://codereview.chromium.org/6756044 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@80626 0039d316-1c4b-4281-b951-d872f2087c98
* Fix for the HTTPSGetTest and GetTest net test failures with ChromeFrame. ↵ananta@chromium.org2011-02-241-1/+1
| | | | | | | | | | | | | | | | | | These failures occurred because of new expectations in these tests which match the server ip address and port being connected to. We need to return that information from ChromeFrame. Fix is to send over the corresponding HostPortPair structure in the AutomationMsg_RequestStarted IPC message. A major part of this CL is basically the groundwork to pass this information over via automation. BUG=none TEST=chrome frame net tests should pass. Review URL: http://codereview.chromium.org/6575027 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@75942 0039d316-1c4b-4281-b951-d872f2087c98
* net: Add namespace net to the remaining files under url_request directory.tfarina@chromium.org2011-01-061-6/+5
| | | | | | | | | | | | It just adds the 'namespace net' to these files and a typedef for them, because there are many entries to fix in one pass. They will be fixed later. BUG=64263 TEST=trybots Review URL: http://codereview.chromium.org/6056007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@70592 0039d316-1c4b-4281-b951-d872f2087c98
* Clean up Automation and Chrome Frame IPC code.-only use routed messages when ↵jam@chromium.org2010-12-231-21/+17
| | | | | | | | needed-use routing IDs to avoid manually unpacking messages-remove data structures from IPC namespace (that should only be used for IPC code, and param traits)Note that I temporarily commented out part of a test in external_tab_test.cc because I couldn't figure out how to get the updated gmock macros to compile. Review URL: http://codereview.chromium.org/5998006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@70105 0039d316-1c4b-4281-b951-d872f2087c98
* Reapply part of r64637, which caused mysterious failures on mac waterfall.erg@google.com2010-11-081-1/+1
| | | | | | | | | | | | | This applies only the rename of IPC::ContextMenuParams to IPC::MiniContextMenuParams so that it doesn't conflict with ::ContextMenuParams (defined in webkit). This is about half the original patch. BUG=51409 TEST=compiles Review URL: http://codereview.chromium.org/4669005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@65429 0039d316-1c4b-4281-b951-d872f2087c98
* Revert "Refactor automation messages." due to mysterious problems on mac.erg@google.com2010-11-011-1/+1
| | | | | | | | | | | | | This reverts commit c1c1fed998ee4d839bfe256150e5e59220ebc0ef (r64637). TBR=nirnimesh@ BUG=51409 TEST=none Review URL: http://codereview.chromium.org/4194007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@64644 0039d316-1c4b-4281-b951-d872f2087c98
* Refactor automation messages.erg@google.com2010-11-011-1/+1
| | | | | | | | | | | | | | | | | automation_messages used to live in chrome/test/automation, when it's needed by browser and chrome_frame. When I started lifting code out of headers and into implementation files, I was getting link errors and temporarily solved the problem by compiling the cc files manually into libbrowser.a. Now this is part of chrome/common/ which is included by all targets needed. While doing this, discover that automation IPC redefines the ContextMenuParams struct. Rename it to MiniContextMenuParams. BUG=51409 TEST=none Review URL: http://codereview.chromium.org/4200007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@64637 0039d316-1c4b-4281-b951-d872f2087c98
* Ensure that ChromeFrame link navigations which occur when the opener frame ↵ananta@chromium.org2010-08-271-3/+3
| | | | | | | | | | | | | | | | | | | is NULL are always reported back to the host browser as top level navigations. The other change is to always send over navigation requests from the automation client even if the url remains the same if the client is already initialized, i.e this is treated as a new navigation. Fixes bug http://code.google.com/p/chromium/issues/detail?id=38456 Bug=38456 Test=The ChromeFrame side of the change is covered by a new chrome frame mock test. Will add a test for the render view change in a subsequent CL. Review URL: http://codereview.chromium.org/3235001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@57748 0039d316-1c4b-4281-b951-d872f2087c98
* Relanding this fix with the fixes to get chrome frame tests to pass.ananta@chromium.org2010-05-181-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | In ChromeFrame the ChromeFrameAutomationProxy object is created on the background proxy channel thread and is accessed from the UI thread, the proxy channel thread and the IPC thread. This leads to a race condition when ChromeFrame is being torn down which occurs because the ChromeFrameAutomationProxy pointer is being set to NULL in the UI thread/deleted in the proxy background thread while it could be accessed while processing a callback in the IPC thread thus causing a crash. Fix is to ensure that the IPC thread does not access the ChromeFrameAutomationProxy pointer. To achieve this the callbacks are now individual context objects which when invoked forward the actions to the ChromeFrameAutomationClient object. The CreateExternalTab and ConnectExternalTab callbacks now complete their actions on the UI thread. While at this based on a discussion and lot of help from Stoyan we decided to clean up the sync message dispatching code used by ChromeFrame by having callbacks now derive from a SyncMessageCallContext class to ensure that these get cleaned up correctly in all cases. For e.g. if we don't receive a response for a message, etc and thus enable them to present a consistent interface to be invoked when we receive a response for a IPc message. Fixes bug http://code.google.com/p/chromium/issues/detail?id=44245 Bug=44245 TBR=stoyan Review URL: http://codereview.chromium.org/2119004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@47494 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 47453 - In ChromeFrame the ChromeFrameAutomationProxy object is ↵ananta@chromium.org2010-05-171-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | created on the background proxy channel thread and is accessed from the UI thread, the proxy channel thread and the IPC thread. This leads to a race condition when ChromeFrame is being torn down which occurs because the ChromeFrameAutomationProxy pointer is being set to NULL in the UI thread/deleted in the proxy background thread while it could be accessed while processing a callback in the IPC thread thus causing a crash. Fix is to ensure that the IPC thread does not access the ChromeFrameAutomationProxy pointer. To achieve this the callbacks are now individual context objects which when invoked forward the actions to the ChromeFrameAutomationClient object. The CreateExternalTab and ConnectExternalTab callbacks now complete their actions on the UI thread. While at this based on a discussion and lot of help from Stoyan we decided to clean up the sync message dispatching code used by ChromeFrame by having callbacks now derive from a SyncMessageCallContext class to ensure that these get cleaned up correctly in all cases. For e.g. if we don't receive a response for a message, etc and thus enable them to present a consistent interface to be invoked when we receive a response for a IPc message. Fixes bug http://code.google.com/p/chromium/issues/detail?id=44245 Bug=44245 Review URL: http://codereview.chromium.org/2073007 TBR=ananta@chromium.org Review URL: http://codereview.chromium.org/2110006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@47461 0039d316-1c4b-4281-b951-d872f2087c98
* In ChromeFrame the ChromeFrameAutomationProxy object is created on the ↵ananta@chromium.org2010-05-171-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | background proxy channel thread and is accessed from the UI thread, the proxy channel thread and the IPC thread. This leads to a race condition when ChromeFrame is being torn down which occurs because the ChromeFrameAutomationProxy pointer is being set to NULL in the UI thread/deleted in the proxy background thread while it could be accessed while processing a callback in the IPC thread thus causing a crash. Fix is to ensure that the IPC thread does not access the ChromeFrameAutomationProxy pointer. To achieve this the callbacks are now individual context objects which when invoked forward the actions to the ChromeFrameAutomationClient object. The CreateExternalTab and ConnectExternalTab callbacks now complete their actions on the UI thread. While at this based on a discussion and lot of help from Stoyan we decided to clean up the sync message dispatching code used by ChromeFrame by having callbacks now derive from a SyncMessageCallContext class to ensure that these get cleaned up correctly in all cases. For e.g. if we don't receive a response for a message, etc and thus enable them to present a consistent interface to be invoked when we receive a response for a IPc message. Fixes bug http://code.google.com/p/chromium/issues/detail?id=44245 Bug=44245 Review URL: http://codereview.chromium.org/2073007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@47453 0039d316-1c4b-4281-b951-d872f2087c98
* Move Urlmon network requests to UI thread, thus allowing reusing the bind ↵stoyan@chromium.org2010-04-081-1/+1
| | | | | | | | | | | | | 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
* Test the new code for propagating OnChannelError to Chrome Frame Delegate.mad@chromium.org2010-03-311-5/+11
| | | | | | | | | | | | | | The new code was added in: http://src.chromium.org/viewvc/chrome?view=rev&revision=42810 More tests are comming. BUG=0 TEST=none Review URL: http://codereview.chromium.org/1571005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@43211 0039d316-1c4b-4281-b951-d872f2087c98
* Added the propagation of the OnChannelError notification.mad@chromium.org2010-03-261-3/+6
| | | | | | | | | | | 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
* 3rd try. *sigh*slightlyoff@chromium.org2010-03-261-7/+9
| | | | | | | | | | | | | See: http://codereview.chromium.org/858003 TBR=tommi BUG=22846 TEST=On IE 8, clear the cache entirely, watch GCF launch (via task manager) Review URL: http://codereview.chromium.org/1343004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42732 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting this CL to see if this fixes chrome frame unit test failures.ananta@chromium.org2010-03-251-9/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Revert 42684 - Implements IDeleteBrowsing history and moves the GCF profile into the IE TIF directory for nonpriv mode users on IE < 8. Implementation notes: Earlier work enabled InPrivate browsing detection and mapped it to creation of an incognito profile instance.Privacy features and how they operate with this change: "Delete Browsing History": IE 6 & 7: all history (including databases) is deleted if cache is cleared *WITHOUT* an active Chrome process holding references to the profile resources. If GCF is rendering a page when the cache is cleared, history *WILL NOT* be deleted on the GCF side, however GCF will continue to operate and IE will remove all other history artifacts as usual. IE 8: GCF cache is cleared in alignment with the options specified by the user. Clearing Temporary Internet Files may destroy the profile entirely, and so we need to consider not moving the GCF profile on IE 8. "InPrivate Filtering": IE 8 (only): more testing required. "InPrivate Browsing": IE 8 (only): pages rendered in GCF *after* entering InPrivate mode are not persisted to disk (use an incognito wrapper on the specified profile). Currently displayed pages are not effected by the switch, although refreshing them will invoke the new behavior. Generally speaking, BHO's are disabled by IE 8 while in InPrivate mode, so entering this state is wonky to begin with but we handle it as well as can be expected. BUG=22846 TEST=On IE 8, clear the cache entirely, note GCF entries in DbgView (better tests coming) Review URL: http://codereview.chromium.org/858003 TBR=slightlyoff@chromium.org Review URL: http://codereview.chromium.org/1353002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42691 0039d316-1c4b-4281-b951-d872f2087c98
* Implements IDeleteBrowsing history and moves the GCF profile into the IE TIF ↵slightlyoff@chromium.org2010-03-251-7/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | directory for non-priv mode users on IE < 8. Implementation notes: Earlier work enabled InPrivate browsing detection and mapped it to creation of an incognito profile instance.Privacy features and how they operate with this change: "Delete Browsing History": IE 6 & 7: all history (including databases) is deleted if cache is cleared *WITHOUT* an active Chrome process holding references to the profile resources. If GCF is rendering a page when the cache is cleared, history *WILL NOT* be deleted on the GCF side, however GCF will continue to operate and IE will remove all other history artifacts as usual. IE 8: GCF cache is cleared in alignment with the options specified by the user. Clearing Temporary Internet Files may destroy the profile entirely, and so we need to consider not moving the GCF profile on IE 8. "InPrivate Filtering": IE 8 (only): more testing required. "InPrivate Browsing": IE 8 (only): pages rendered in GCF *after* entering InPrivate mode are not persisted to disk (use an incognito wrapper on the specified profile). Currently displayed pages are not effected by the switch, although refreshing them will invoke the new behavior. Generally speaking, BHO's are disabled by IE 8 while in InPrivate mode, so entering this state is wonky to begin with but we handle it as well as can be expected. BUG=22846 TEST=On IE 8, clear the cache entirely, note GCF entries in DbgView (better tests coming) Review URL: http://codereview.chromium.org/858003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42684 0039d316-1c4b-4281-b951-d872f2087c98
* ChromeFrame should honor the host browser's cookie policy. To achieve this ↵ananta@chromium.org2010-03-021-1/+1
| | | | | | | | | | | | | | | | 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
* Fix the ui test crashes on Linux. There is a race condition between the ↵ananta@chromium.org2010-02-261-1/+1
| | | | | | | | | | | | | | channel getting destroyed and it being referenced in the background thread. Fix is to use the underlying IPC::Channel pointer passed to the message filter when the filter gets Added to send and receive messages. This ensures that the SyncChannel is not used across threads. Review URL: http://codereview.chromium.org/661109 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@40076 0039d316-1c4b-4281-b951-d872f2087c98
* Reorganize chrome_frame_unittest.h/ccamit@chromium.org2010-02-041-0/+176
Split this monsterinto 4 different h/cc files based on the type of tests. No real code changes. Things should become easier to find/manage now. BUG=None TEST=None Review URL: http://codereview.chromium.org/574006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@38144 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-01-30 10:09:18 +0000