Initial HTTP requests issued by ChromeFrame popups could bypass the host network stack. The host network

stack in ChromeFrame intercepts HTTP requests based on registered render views. When a popup window is created
we register it in the AddNewContents notification on the TabContentsDelegate. This is a little late as network
requests could be issued before the view actually becomes visible.

To fix this we now have a new method in the TabContentsDelegate interface called TabContentsCreated which
notifies the delegate about the creation of a new TabContents. The ExternalTabContainer implements this
method and registers the render view as pending. I also changed the signature of the
RenderViewHostDelegateViewHelper::CreateNewWindow method to return the new TabContents.

As part of this fix we also unregister the render view when the ExternalTabContainer is deleted. The
container registers for the NotificationType::RENDER_VIEW_HOST_DELETED notification. However we end up
deleting the TabContents in WM_DESTROY, which results in the container never receiving this notification.

Fixes bug http://code.google.com/p/chromium/issues/detail?id=36323

Bug=36323
Test=Will be covered by the automation proxy test which Stoyan is adding

Review URL: http://codereview.chromium.org/652009

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@39611 0039d316-1c4b-4281-b951-d872f2087c98

0 files changed, 0 insertions, 0 deletions