summaryrefslogtreecommitdiffstats
path: root/chrome_frame/chrome_frame_automation.cc
Commit message (Collapse)AuthorAgeFilesLines
* Add DISABLE_RUNNABLE_METHOD_REFCOUNT to make disabling refcounts in ↵ajwong@chromium.org2010-06-161-4/+1
| | | | | | | | | | | RunnableMethods easier. BUG=none TEST=none Review URL: http://codereview.chromium.org/2830006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@49887 0039d316-1c4b-4281-b951-d872f2087c98
* Move the crash metrics to the crash reproting lib to avoid a back dependency ↵mad@google.com2010-06-121-1/+1
| | | | | | | | | | | on Chrome Frame. BUG=0 TEST=none Review URL: http://codereview.chromium.org/2776010 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@49635 0039d316-1c4b-4281-b951-d872f2087c98
* Add support for uploading UMA metrics data from ChromeFrame. Added support ↵ananta@chromium.org2010-06-111-3/+14
| | | | | | | | | | | | | | | | for tracking chrome frame crash metrics via 2 new counters which track successful navigations and crashes. These counters are persisted in the registry under HKCU\Software\Google\ChromeFrameMetrics. Any other histogram data like AutomationServer launch time, IE versions etc are simply dropped if IE is shutdown before they are sent out. The metrics data is uploaded on similar lines as Chrome. Bug=46057 Review URL: http://codereview.chromium.org/2714003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@49493 0039d316-1c4b-4281-b951-d872f2087c98
* Relanding 49339 jcivelli@chromium.org2010-06-101-2/+0
| | | | | | | | | | | | | It was unjustly reverted due to flaky unit-test failure. Original review: http://codereview.chromium.org/2358003 TBR=ctguil@chromium.org Review URL: http://codereview.chromium.org/2720003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@49344 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 49339 - Enable renderer accessibility by default.jcivelli@chromium.org2010-06-101-0/+2
| | | | | | | | | | | | | | It seems to be breaking the ExtensionAPIClientTest.CreateWindowW unit-test. BUG=25564 TEST=none Review URL: http://codereview.chromium.org/2358003 TBR=ctguil@chromium.org Review URL: http://codereview.chromium.org/2782003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@49343 0039d316-1c4b-4281-b951-d872f2087c98
* Enable renderer accessibility by default.ctguil@chromium.org2010-06-091-2/+0
| | | | | | | | | BUG=25564 TEST=none Review URL: http://codereview.chromium.org/2358003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@49339 0039d316-1c4b-4281-b951-d872f2087c98
* Navigating to a page in ChromeFrame in IE would display the sad tab page ↵ananta@chromium.org2010-06-031-0/+3
| | | | | | | | | | | | | | | briefly until the navigation was initiated from IE. We have code in the ChromeFrame external tab container to initiate the navigation during initialization if we have a valid url passed in while creating the external tab. The URL would not get passed down even though it was available from ChromeFrame. This fixes bug http://code.google.com/p/chromium/issues/detail?id=43482 Bug=43482 Review URL: http://codereview.chromium.org/2600002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@48890 0039d316-1c4b-4281-b951-d872f2087c98
* Rewrite of chrome_launcher.exe. ETW-based perf tests suggest that this is on ↵robertshield@chromium.org2010-05-281-1/+1
| | | | | | | | average about 50% faster than the previous version. Review URL: http://codereview.chromium.org/2278003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@48500 0039d316-1c4b-4281-b951-d872f2087c98
* Fix the ChromeFrame MockCreateTabOk test by returning the launch result from ↵ananta@chromium.org2010-05-191-4/+5
| | | | | | | | | | | | | | the CreateExternalTabComplete helper and passing the same to the InitializeComplete function which eventually gets passed down to the mock delegate which expects a failure. Bug=44245 TBR=stoyan Review URL: http://codereview.chromium.org/2114009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@47617 0039d316-1c4b-4281-b951-d872f2087c98
* Fix the ChromeFrame new window popup test by ensuring that ↵ananta@chromium.org2010-05-191-6/+6
| | | | | | | | | | | | | | | | | CreateExternalTabComplete executes on the IPC thread as before and InitializeComplete executes as a task on the UI thread. The test failed because we receive IPCs for the new tab before we have a tab proxy for it. To fix the crash in bug http://code.google.com/p/chromium/issues/detail?id=44245, we set the automation_server_ member to NULL after ReleaseAutomationServer returns. There are a number of races related to the automation server being released which should hopefully go away if we remove dependency on the AutomationProxy object. Added a TODO to that effect in the code. Bug=44245 Review URL: http://codereview.chromium.org/2079012 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@47612 0039d316-1c4b-4281-b951-d872f2087c98
* Relanding this fix with the fixes to get chrome frame tests to pass.ananta@chromium.org2010-05-181-93/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-128/+92
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-92/+128
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* ChromeFrame would not switch to Chrome at times. The navigation manager in ↵ananta@chromium.org2010-05-121-2/+1
| | | | | | | | | | | | | | | | | | | | | | ChromeFrame maintains the current top level URL which is used by the moniker patch to decide whether to wrap the callback. This url is typically set in the Bho in the BeforeNavigate callback. We also had code to update this url when we receive a navigation update from Chrome. The reason we would not switch is because of a race condition between receiving a top level navigation request from chrome and receiving a navigation update for the previous operation which caused us to not wrap the bind status callback. Fix is to not update the url in the callback when we receive a navigation status update. In any case it is Chrome's responsibility to inform ChromeFrame about top level url navigations. We should fix the bug if any in Chrome which caused this hack to go in. Fixes bug http://code.google.com/p/chromium/issues/detail?id=43922 Other changes are to replace the NOTREACHED in the chrome frame automation proxy code with a DLOG as this fires during chrome frame test runs. Bug=43922 Review URL: http://codereview.chromium.org/1991008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@47086 0039d316-1c4b-4281-b951-d872f2087c98
* Instrument Chrome and Chrome Frame for some perf measurements.siggi@chromium.org2010-05-101-0/+8
| | | | | | | | | BUG=none TEST=none Review URL: http://codereview.chromium.org/1989005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@46812 0039d316-1c4b-4281-b951-d872f2087c98
* Opening new chrome frame tabs would fail randomly. This was because of a ↵ananta@chromium.org2010-05-071-0/+3
| | | | | | | | | | | | | | | | | | | race condition between processing the connect external tab ack in chrome frame and receiving requests for the tab. As a result the new tabs would not render anything. Fix is to resume the pending views in the OnReinitialize task in the ExternalTabContainer. I also added a NOTREACHED when we fail to find the TabProxy for a tab handle in the chrome frame automation code to help catch future instances of this issue. Fixes bug http://code.google.com/p/chromium/issues/detail?id=43376 Bug=43376 Review URL: http://codereview.chromium.org/2011006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@46643 0039d316-1c4b-4281-b951-d872f2087c98
* Preparation CL for executing READ and COOKIE network requests from the ↵stoyan@chromium.org2010-04-131-31/+33
| | | | | | | | 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-2/+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
* Speculative fix for a ChromeFrame crash reported on the crash server. The ↵ananta@chromium.org2010-04-071-1/+7
| | | | | | | | | | | | | | | | | | | crash occurs when the ChromeFrame active document instance is torn down. This takes down the automation client instance which handles communication with Chrome. When the automation client instance is torn down it tries to stop pending chrome requests which causes a crash because of an invalid url fetcher object. This could only happen if the url fetcher object belongs to a deleted active document instance, which could occur if the automation client instance was reused during a Reinitialize operation which failed. Fix is to tear down the pending url requests at the top of the Reinitialize function before checking for failure cases. Should fix bug http://code.google.com/p/chromium/issues/detail?id=40590 Bug=40590 Review URL: http://codereview.chromium.org/1524015 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@43797 0039d316-1c4b-4281-b951-d872f2087c98
* Reenable the ChromeFrame unload event test which basically loads a page ↵ananta@chromium.org2010-03-261-0/+29
| | | | | | | | | | | | | | | | | | | | | 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
* Added the propagation of the OnChannelError notification.mad@chromium.org2010-03-261-5/+53
| | | | | | | | | | | 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
* Committing for Eric Dingle.mad@chromium.org2010-03-261-16/+10
| | | | | | | | | | http://codereview.chromium.org/890005 BUG=0 TEST=none git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42800 0039d316-1c4b-4281-b951-d872f2087c98
* 3rd try. *sigh*slightlyoff@chromium.org2010-03-261-24/+12
| | | | | | | | | | | | | 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-12/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-24/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add support for grabbing full dumps from chrome in ChromeFrame reliability ↵ananta@chromium.org2010-03-251-0/+5
| | | | | | | | | | test runs. This is only done if ChromeFrame is running in headless mode. Review URL: http://codereview.chromium.org/1346003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42677 0039d316-1c4b-4281-b951-d872f2087c98
* Fix for a race issue when chrome decides that a request needs to be ↵tommi@chromium.org2010-03-251-0/+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
* Revert 42366 - Allow TabContentsDelegate classes to specify whether InfoBars ↵joi@chromium.org2010-03-231-10/+15
| | | | | | | | | | | | | | | | are enabled. Allow ChromeFrame to pass infobar enabled parameter to ExternalTabContainer. BUG=2444936 Patch contributed by ericdingle@google.com Original review at http://codereview.chromium.org/890005 TBR=joi@chromium.org Review URL: http://codereview.chromium.org/1205001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42378 0039d316-1c4b-4281-b951-d872f2087c98
* Allow TabContentsDelegate classes to specify whether InfoBars are enabled.joi@chromium.org2010-03-231-15/+10
| | | | | | | | | | | Allow ChromeFrame to pass infobar enabled parameter to ExternalTabContainer. BUG=2444936 Patch contributed by ericdingle@google.com Original review at http://codereview.chromium.org/890005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42366 0039d316-1c4b-4281-b951-d872f2087c98
* Adds an automation message to retrieve the list of enabled extensions, and ↵joi@chromium.org2010-03-161-0/+69
| | | | | | | | | | | 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-31/+29
| | | | | | | | | | | | 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-5/+14
| | | | | | | | | | | 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
* Fix a ChromeFrame crash which occured in the Histogram code while adding a ↵ananta@chromium.org2010-03-051-12/+19
| | | | | | | | | | | | | | | | | | histogram. The histogram macros basically instantiate a static Histogram instance which is then tracked. The static initialization is not thread safe and thus could cause a crash if there is a race between multiple threads trying to access the object at the same time. Fix based on a discussion with Jim is to add thread safe versions of the macros we use for ChromeFrame. Fixes bug http://code.google.com/p/chromium/issues/detail?id=37470 Bug=37470 Review URL: http://codereview.chromium.org/669135 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@40757 0039d316-1c4b-4281-b951-d872f2087c98
* ChromeFrame should honor the host browser's cookie policy. To achieve this ↵ananta@chromium.org2010-03-021-3/+2
| | | | | | | | | | | | | | | | 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
* Make sure we have a valid tab proxy before trying to call it.mad@chromium.org2010-02-191-1/+8
| | | | | | | | | | | Got a crash while testing something else on a VM and my investigation led to that potential problem. BUG=0 TEST=Try loading Chrome Frame on very slow machines (like a VM). Review URL: http://codereview.chromium.org/651036 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@39481 0039d316-1c4b-4281-b951-d872f2087c98
* Pulled out Callback code into base/callback.h. This is the first step ↵akalin@chromium.org2010-02-191-0/+1
| | | | | | | | | | | | | towards redoing the Callback interfaces. Added and removed includes as needed. BUG=35223 TEST=trybots Review URL: http://codereview.chromium.org/646061 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@39419 0039d316-1c4b-4281-b951-d872f2087c98
* Fix for referrer flakyness. There were two problems:tommi@chromium.org2010-02-181-1/+6
| | | | | | | | | | | | | | | Grabbing the referrer header when the request is made and not in BeforeNavigate2. The request headers aren't always available in BeforeNavigate2. Mshtml provides these headers in IHttpNegotiate::BeginningTransaction, which is where we now grab them. There was a race in chrome_frame_automation.cc where we use std::string to store the referrer url and then access that string from different threads. This was causing the referrer URL to be missing at some times and at other times be sent over to chrome as bad string (e.g. containing embedded nulls) and subsequently be deemed an invalid URL and dropped. TEST=Fixes referrer header flakyness. BUG=34812 Review URL: http://codereview.chromium.org/646013 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@39383 0039d316-1c4b-4281-b951-d872f2087c98
* Clone of issue 600130. (http://codereview.chromium.org/600130)twiz@chromium.org2010-02-161-0/+4
| | | | | | | | | 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
* Fix crash. Happens in LaunchDelegate::LaunchComplete if delegate ↵stoyan@chromium.org2010-02-101-12/+30
| | | | | | | | | | (ChromeFrameAutomationClient) is destroyed before launch callback is invoked. Happens when underlying automation proxy is going to be shared to new instance of ChromeFrameAutomationClient and we destroy that instance before receiving LaunchComplete callback. Still have a race (and possible crash) for automation_server_ in ReleaseAutomationServer and LaunchComplete, TEST=test added. Review URL: http://codereview.chromium.org/582018 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@38551 0039d316-1c4b-4281-b951-d872f2087c98
* Fix race conditions.stoyan@chromium.org2010-02-031-5/+5
| | | | | | | | BUG=34389 Review URL: http://codereview.chromium.org/564041 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@38021 0039d316-1c4b-4281-b951-d872f2087c98
* TEST=new tests added.stoyan@chromium.org2010-02-011-116/+91
| | | | | | Review URL: http://codereview.chromium.org/545093 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@37728 0039d316-1c4b-4281-b951-d872f2087c98
* 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
generated by cgit v1.1 at 2025-01-17 23:21:01 +0000