diff options
| author | ananta@chromium.org <ananta@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-09-06 15:27:14 +0000 |
|---|---|---|
| committer | ananta@chromium.org <ananta@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-09-06 15:27:14 +0000 |
| commit | 632fbb17bac3bca1c0a6e8f45a7357eefae9925f (patch) | |
| tree | b60a2e560bf833d2e4537ef57f1c544ae5a72610 /chrome/browser/tab_contents | |
| parent | a0663ed7b609539c522dfff1238a6866e236b350 (diff) | |
| download | chromium_src-632fbb17bac3bca1c0a6e8f45a7357eefae9925f.zip chromium_src-632fbb17bac3bca1c0a6e8f45a7357eefae9925f.tar.gz chromium_src-632fbb17bac3bca1c0a6e8f45a7357eefae9925f.tar.bz2 | |
Chrome side of the fix for http://b/issue?id=1694574, which is a bug caused when a new automation client instance is launched and attempts to attach to an existing external tab. An example of where this could happen is javascript on a page attempting a window.open with target _blank. In this case the Chrome browser creates a TabContents instance which is attached to an ExternalTabContainer instance. The automation client then attaches to this ExternalTabContainer. This all works if the automation client is in the same client process. If a new process is launched a separate automation channel is created between the client and the chrome browser which causes this to not work as expected.
Fix is have a floating ExternalTabContainer instance which is eventually connected to by the client. When we receive a notification from the client that it is about to connect to the ExternalTabContainer instance we setup the automation channel and other info in the underlying automation profile.
The new TabContents is created with the same profile instance as the current TabContents. This does not
work correctly if the underlying profile is an automation profile as its lifetime is tied to the
ExternalTabContainer. To fix this I added a setter for the new policy to the NavigationController. Not doing
this causes the browser to crash if the original ExternalTabContainer instance dies.
There is a bigger issue here which is that all this profile sharing would cause session cookies to not work correctly if multiple automation clients are connected to the same Chrome browser instance over the same profile. I will file a separate bug to track this issue.
Bug=1694574
Review URL: http://codereview.chromium.org/200003
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@25594 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'chrome/browser/tab_contents')
| -rw-r--r-- | chrome/browser/tab_contents/navigation_controller.h | 5 |
1 files changed, 5 insertions, 0 deletions
diff --git a/chrome/browser/tab_contents/navigation_controller.h b/chrome/browser/tab_contents/navigation_controller.h index 9be8437..3d0d6cd 100644 --- a/chrome/browser/tab_contents/navigation_controller.h +++ b/chrome/browser/tab_contents/navigation_controller.h @@ -138,6 +138,11 @@ class NavigationController { return profile_; } + // Sets the profile for this controller. + void set_profile(Profile* profile) { + profile_ = profile; + } + // Initializes this NavigationController with the given saved navigations, // using selected_navigation as the currently loaded entry. Before this call // the controller should be unused (there should be no current entry). This is |