Delete the download shelf before we destroy the browser

chrome/browser/ui/views/frame/browser_view.cc

Index: chrome/browser/ui/views/frame/browser_view.cc
diff --git a/chrome/browser/ui/views/frame/browser_view.cc b/chrome/browser/ui/views/frame/browser_view.cc
index b184e79976eb2eb60b967db3bf5022f4e9a94be1..c180158a60f655517894e5ce20e026aca1902811 100644
--- a/chrome/browser/ui/views/frame/browser_view.cc
+++ b/chrome/browser/ui/views/frame/browser_view.cc
@@ -952,6 +952,8 @@ void BrowserView::DestroyBrowser() {
   // worry about the BookmarkBarView potentially outliving the Browser &
   // Profile.
   bookmark_bar_view_.reset();
+  // Ditto for DownloadShelfView.
+  download_shelf_.reset();

[Ben Goodger (Google), 2011/06/01 20:47:50]

My question is - what other views are there that this might apply to? Are both
of these views not parent owned? Are there any others?

Who calls this?

[asanka, 2011/06/01 21:06:42]

This is called by BrowserList::CloseAllBrowsers(), which can be called while
processing a WM_ENDSESSION message.

The problem here is that DownloadItemView shouldn't outlive the Browser.  On a
more general note, I think the comment in ~BrowserView also applies here:

  // Child views maintain PrefMember attributes that point to
  // OffTheRecordProfile's PrefService which gets deleted by ~Browser.
  RemoveAllChildViews(true);
  // Explicitly set browser_ to NULL.
  browser_.reset();

So perhaps we should RemoveAllChildViews() before we destroy browser_ in
DestroyBrowser().  I'll look and see what else might go wrong when we destroy
the browser_ while the BrowserView is still around.

   browser_.reset();
 }