summaryrefslogtreecommitdiffstats
path: root/chrome_frame/chrome_frame_automation.cc
Commit message (Collapse)AuthorAgeFilesLines
* Revert of a revert of a patch that re-enabled automation protocol version ↵robertshield@chromium.org2010-10-211-0/+4
| | | | | | | | | | | | | | mismatch checking in CF. Original revision: r63211 Revert revision: r63239 Previously, our version information wasn't getting updated properly through incremental builds which made the test builders unhappy. That was fixed in r63355. This should now be safe to commit. Review URL: http://codereview.chromium.org/4034004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@63364 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting this as this causes a message box to show up on the builders ↵ananta@chromium.org2010-10-201-4/+0
| | | | | | | | | | | | | | | | | | | | | indicating that the chrome and chrome frame versions are different which they are. Perhaps the version resource in chrome frame is just wrong and needs a clobber. Robert please investigate and reland Revert 63211 - Re-add the version mismatch checking which was removed at some point. Also add version information to chrome_frame_tests.exe. This will be needed for subsequent tests. Review URL: http://codereview.chromium.org/3879001 TBR=robertshield@chromium.org Review URL: http://codereview.chromium.org/3939002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@63239 0039d316-1c4b-4281-b951-d872f2087c98
* Re-add the version mismatch checking which was removed at some point. Also ↵robertshield@chromium.org2010-10-201-0/+4
| | | | | | | | add version information to chrome_frame_tests.exe. This will be needed for subsequent tests. Review URL: http://codereview.chromium.org/3879001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@63211 0039d316-1c4b-4281-b951-d872f2087c98
* Various changes to make GCF nicer for the non-en-US world:grt@chromium.org2010-10-201-2/+7
| | | | | | | | | | | | | - Chrome Frame now uses MUI on Vista+ to detect IE's UX language. - Chrome Frame now tells Chrome (via the --lang command-line option) what the current langauge is. - Chrome Frame now respects Chrome's "ApplicationLocaleValue" group policy setting. BUG=56435,59582 TEST=chrome_frame_unittests and chrome_frame_tests updated Review URL: http://codereview.chromium.org/3757007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@63208 0039d316-1c4b-4281-b951-d872f2087c98
* Convert LOG(INFO) to VLOG(1) - chrome_frame/.pkasting@chromium.org2010-10-191-5/+5
| | | | | | | | | | Plus a couple misc. cleanups. BUG=none TEST=none Review URL: http://codereview.chromium.org/3850002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@63095 0039d316-1c4b-4281-b951-d872f2087c98
* Top level navigations are not sent to the host browser in the ChromeFrame ↵ananta@chromium.org2010-09-301-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | NPAPI implementation. These include window.open requests, hrefs with target _blank, etc. The ChromeFrame NPAPI plugin needs to set the renderer pref which indicates that the host browser can handle top level requests. We also pass an additional flag in the CreateExternal tab IPC which indicates whether the host browser supports full tab mode browsing or not. This defaults to true for IE, as the activex implementation relies on being able to launch a new window with the attach external tab prefix. which assumes support for full tab mode for IE being available. If the host browser does not support full tab browsing the window.open request which comes into the ExternalTabContainer instance creates a dummy ExternalTabContainer instance which is destroyed when the top level navigation info is sent back to the host browser. This CL is a short term fix for the issues with the NPAPI ChromeFrame plugin. Will do some investigation into a better approach. Fixes bug http://code.google.com/p/chromium/issues/detail?id=57319 Test=Covered by existing ChromeFrame widget mode tests WidgetModeIE_SrcProperty and WidgetModeFF_SrcProperty Fixed incorrect assumptions in the test files used by these tests. Bug=57319 Review URL: http://codereview.chromium.org/3549006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@61117 0039d316-1c4b-4281-b951-d872f2087c98
* Remove code that enables renderer accessibility based on the ↵ctguil@chromium.org2010-09-181-0/+5
| | | | | | | | | | | | | SPI_GETSCREENREADER parameter. Update chrome frame so that its test automation can still use renderer accessibility. BUG=55902 TEST=none Review URL: http://codereview.chromium.org/3383010 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@59899 0039d316-1c4b-4281-b951-d872f2087c98
* Added full support for invoking before unload and unload handlers on ↵ananta@chromium.org2010-09-171-13/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | ChromeFrame rendered pages. This allows a webpage to put up a confirmation dialog in its beforeunload handler and potentially cancel the operation. We only support invoking unload handlers on the page for IE full tab mode. To achieve this the active document handles the OLECMDID_ONUNLOAD exec command which is passed by the DOCHOST to the object which allows us to potentially cancel the operation. Thanks to Stoyan for his help in authoring parts of this CL. The AutomationMsg_RunUnloadHandlers message which is used only by ChromeFrame is now a sync message which returns back a bool indicating whether the unload operation can be continued or not. The ExternalTabContainer now implements the BeforeUnloadFired method in the TabContentsDelegate and aborts the unload operation if the user chose to not proceed with the unload. Fixes bug http://code.google.com/p/chromium/issues/detail?id=33200 Bug=33200 Test=Covered by existing unload event test. Will add a test which validates whether a page can cancel the unload operation in a subsequent CL. Review URL: http://codereview.chromium.org/3450014 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@59854 0039d316-1c4b-4281-b951-d872f2087c98
* Add lock since the add/remove tabproxy is invoked from different threads.stoyan@chromium.org2010-09-021-0/+3
| | | | | | | BUG=53963 Review URL: http://codereview.chromium.org/3306003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@58367 0039d316-1c4b-4281-b951-d872f2087c98
* Silencing a couple of dchecks that occur when running the debug version of ↵tommi@chromium.org2010-08-311-1/+6
| | | | | | | | | | | the *TabCrashReload* tests. TEST=Run debug versions of *TabCrashReload* tests. There should be no more dchecks. BUG=none Review URL: http://codereview.chromium.org/3241008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@58067 0039d316-1c4b-4281-b951-d872f2087c98
* When GCF is the default renderer, use Chrome's User-agent header instead of ↵tommi@chromium.org2010-08-311-2/+5
| | | | | | | | | | | IE's. TEST=Set IsDefaultRenderer to 1 (REG_DWORD) under the ChromeFrame registry key. Check if the User agent header in requests is the Chrome user agent. Then set the value to 0 and make sure the regular user-agent header is there. BUG=50788 Review URL: http://codereview.chromium.org/3130016 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@57991 0039d316-1c4b-4281-b951-d872f2087c98
* Ensure that ChromeFrame link navigations which occur when the opener frame ↵ananta@chromium.org2010-08-271-1/+5
| | | | | | | | | | | | | | | | | | | 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
* GTTF: After timeout, all further automation calls should fail immediately.phajdan.jr@chromium.org2010-08-191-1/+1
| | | | | | | | | | | | | If IPC send fails, further automation calls are extremely likely to fail. Avoid wasting a lot of time on further timeouts by closing the channel immediately on the first error. TEST=ui_tests BUG=51346 Review URL: http://codereview.chromium.org/3131020 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@56722 0039d316-1c4b-4281-b951-d872f2087c98
* Remove all wstrings from the IPC logging subsystem.erg@google.com2010-08-181-0/+1
| | | | | | | | | | | | | | | | Changes all IPC Log methods from wstring to string. All static logging debug data changed from wchar[] to char[]. Various string conversion/numeric headers no longer need to be included in ipc_message_utils.h and have been removed (and added in all implementation files that require them). BUG=none TEST=none Review URL: http://codereview.chromium.org/3159013 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@56563 0039d316-1c4b-4281-b951-d872f2087c98
* Restrict unsafe URLs in Chrome Frameamit@chromium.org2010-08-131-5/+20
| | | | | | | | | | | | | | | | | | | | | | | | Further tighten down what URLs can be loaded in Chrome Frame. Based on the feedback from the security review and code inspection, restrict about: scheme only to about:blank and about:version by default. Factor out logic blocking logic including for URL zone checking so that all ActiveX, ActiveDoc and NPAPI will follow the same path. As a result we now block restricted URL zones in NPAPI instance as well. Another side effect of this refactoring is that the registry flag, EnableGcfProtocol, is replaced by AllowUnsafeURLs. If If this flag is set, then all the security related checking is turned off. BUG=50741 TEST=By default gcf: works only for about:blank, about:version and view-source of http and https. Setting AllowUnsafeURLs to a non zero value should allow any URL be loaded via gcf: Review URL: http://codereview.chromium.org/3159006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@56096 0039d316-1c4b-4281-b951-d872f2087c98
* Attempt to fix chrome frame tests crash on the IE6 builder. The crash occurs ↵ananta@chromium.org2010-08-121-0/+10
| | | | | | | | | | | | | | | | | | | when ProxyCache singleton object is being torn down with valid AutomationProxyCache entries. These objects in turn try to take down the AutomationProxy which causes a crash in the sync channel while dereferencing a NULL message loop. This appears to be a sideeffect of the changes to display a sad tab in ChromeFrame when chrome crashes. Proposed hack/fix is to leak the automation proxy in this case, which basically falls back to the old behavior. The correct fix would be to refactor/fix the AutomationProxy code to avoid the use of the sync channel if possible. TBR=tommi Review URL: http://codereview.chromium.org/3159009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@55849 0039d316-1c4b-4281-b951-d872f2087c98
* Handle automation server crashes. When Chrome crashes, we now handle the ↵tommi@chromium.org2010-08-101-174/+270
| | | | | | | | | | | | | | case and support document refresh or reload. When chrome crashes, we draw a poor man's sad tab (":-("), so that can clearly be improved. Another thing is that if the chrome instance that crashed held several navigational entries, then that history is lost. TEST=There are a couple of tests included, so run those (*TabCrash*) and also verify that when the chrome automation server is killed that we do the right thing. Also check info in bug report. BUG=25839 Review URL: http://codereview.chromium.org/3061036 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@55565 0039d316-1c4b-4281-b951-d872f2087c98
* Added support in Chromeframe full tab mode IE for setting zoom levels via ↵ananta@chromium.org2010-08-091-0/+7
| | | | | | | | | | | | | | | | | | | | View->Zoom. Currently we only support Zoom in and zoom out as Chrome only supports these zoom levels. Added an automation IPC message AutomationMsg_SetZoomLevel to set the zoom level in ChromeFrame. The other change is in the active document in the handling of the attach external tab message. We now honor the dimensions if any when we Launch the URL. This ensures that any windows opened outside chrome frame also honor these dimensions. Fixes bug http://code.google.com/p/chromium/issues/detail?id=36000 Bug=36000 Review URL: http://codereview.chromium.org/3064049 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@55494 0039d316-1c4b-4281-b951-d872f2087c98
* Convert a bunch of easy AppendSwitchWithValue to *ASCII.evan@chromium.org2010-07-301-2/+2
| | | | | | | | | For this patch, I skipped over any instance where it wasn't a nearly trivial change. Review URL: http://codereview.chromium.org/3069014 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@54285 0039d316-1c4b-4281-b951-d872f2087c98
* Miscellaneous ChromeFrame code cleanup. The automation client class ↵ananta@chromium.org2010-07-301-21/+27
| | | | | | | | | | | | | | maintained GURL members holding the url and referrer. We can stuff this information into the ChromeFrameLaunchParams member maintained by the client. This reduces the complexity in the code related to detecting whether we can navigate up front or after chrome initialization. The ChromeFrame ActiveX now launches the automation server in its implementation of IPersistPropertyBag::Load. This avoids race conditions between launching the automation server and navigating to it via put_src. Review URL: http://codereview.chromium.org/3038038 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@54284 0039d316-1c4b-4281-b951-d872f2087c98
* CommandLine: add a CopySwitchesFrom() and AppendSwitchPath()evan@chromium.org2010-07-291-3/+2
| | | | | | | | | | | These are two common patterns in Chrome code: copying a subset of switches from one CommandLine to another, and appending a FilePath to a CommandLine. This sets me up to do a lot more deprecation in a follow-up change. Review URL: http://codereview.chromium.org/3012021 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@54218 0039d316-1c4b-4281-b951-d872f2087c98
* Fix IE crash while attempting to send the AutomationMsg_RunUnloadHandlers ↵ananta@chromium.org2010-07-151-3/+9
| | | | | | | | | | | IPC on a NULL automation server. Bug=49132 TBR=amit Review URL: http://codereview.chromium.org/2868052 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@52546 0039d316-1c4b-4281-b951-d872f2087c98
* ChromeFrame tabs would hang at times while closing. This would randomly ↵ananta@chromium.org2010-07-151-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | occur if the page had an unload handler. We execute unload handlers in the WM_DESTROY message in the external tab and spin a nested loop waiting for the unload handlers to finish. This causes a deadlock at times if a windows message is dispatched to IE which is blocked in DestroyWindow. The fix is to remove the nested loop mess from the external tab and instead send over a special automation message to Chrome in which context we execute the unload handlers. The message contains the notification window and the actual window message to be posted back when the unload handlers finish executing. The active document/activex spin a GetMessage loop waiting for this message to arrive. To ensure that we don't wait indefinitely we have a 1 second timer and exit the loop if this timer is received. Fixes bug http://code.google.com/p/chromium/issues/detail?id=49132 Bug=49132 Test=Covered by existing unload event test. Review URL: http://codereview.chromium.org/3014001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@52523 0039d316-1c4b-4281-b951-d872f2087c98
* ChromeFrame would leave chrome processes running if a page rendered in ↵ananta@chromium.org2010-07-121-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | Chrome would open up a popup window which opened up in IE. This is because of an orphan external tab container created to handle the popup. This tab is destroyed in the normal case when the active document window is destroyed, which is the parent of the external tab container. However in this case the active document is destroyed without its window being created thus resulting in the external tab container lying around which holds a reference to the automation provider. Fix is to pass the ChromeFrameAutomationClient window as the parent window in the AutomationMsg_ConnectExternalTab message. Fixes bug http://code.google.com/p/chromium/issues/detail?id=48732 Bug=48732 Covered by ChromeFrame test FullTabNavigationTest.JavascriptWindowOpenDifferentDomain Review URL: http://codereview.chromium.org/2911006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@52094 0039d316-1c4b-4281-b951-d872f2087c98
* 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
generated by cgit v1.1 at 2024-09-16 12:19:22 +0000