diff options
| author | ananta@chromium.org <ananta@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2010-02-03 21:38:08 +0000 |
|---|---|---|
| committer | ananta@chromium.org <ananta@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2010-02-03 21:38:08 +0000 |
| commit | e56e96f80ce491b23454a039ae5eba1a1c6ee3f9 (patch) | |
| tree | 0cd3a2bb9352b35a7caff1287b310686776e2751 /net/base/cookie_store.h | |
| parent | 8c07fdb39d54c0bddcadc563a1d380ce56b3c9a5 (diff) | |
| download | chromium_src-e56e96f80ce491b23454a039ae5eba1a1c6ee3f9.zip chromium_src-e56e96f80ce491b23454a039ae5eba1a1c6ee3f9.tar.gz chromium_src-e56e96f80ce491b23454a039ae5eba1a1c6ee3f9.tar.bz2 | |
The ExternalTabContainer enters a modal loop while waiting for the unload events on the tab to complete.
If multiple ChromeFrame tabs were closed together then we end up in a nested loop hierarchy. In this case
the innermost message loop ends up dispatching the TabContents::Close method which then calls its
delegate which is the ExternalTabContainer for the other ExternalTabs as well. As a result the outer loops
never exit, which causes IE tabs to hang.
Fix is to use a local global stack of ExternalTabContainers. If we receive a CloseContents call for any other
container but the innermost one, we post it back to the loop.
Bug=31853
Review URL: http://codereview.chromium.org/560034
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@38022 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'net/base/cookie_store.h')
0 files changed, 0 insertions, 0 deletions