Fixing crash in StartFinding (2nd attempt).

The first attempt to fix this was unsuccessful and crashes showed
up again during the automated ui testing. I still can't reproduce
locally, but when I look again at the crash dump I think that the
fact that it looked like the FindBarView was destroyed is misleading
and the real issue is the same as with the crash in StopFinding
(that web_contents has been destroyed moments before we receive the
request).

I am therefore removing the code I added earlier and replacing it
with a null check for web_contents.

TEST=Covered by automated ui tests.
BUG=8048

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

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

chrome/browser/views/find_bar_view.cc

@@ -168,10 +168,6 @@ FindBarView::FindBarView(FindBarWin* container)
 }
 
 FindBarView::~FindBarView() {
-  // We are going away so we don't want to be notified about further updates
-  // to the text field. Otherwise, it can lead to crashes, as exposed by
-  // automation testing in issue 8048.
-  find_text_->SetController(NULL);
 }
 
 void FindBarView::SetFindText(const std::wstring& find_text) {
@@ -444,6 +440,12 @@ void FindBarView::ButtonPressed(views::BaseButton* sender) {
 
 void FindBarView::ContentsChanged(views::TextField* sender,
                                   const std::wstring& new_contents) {
+  // We must guard against a NULL web_contents, which can happen if the text
+  // in the Find box is changed right after the tab is destroyed. Otherwise, it
+  // can lead to crashes, as exposed by automation testing in issue 8048.
+  if (!container_->web_contents())
+    return;
+
   // When the user changes something in the text box we check the contents and
   // if the textbox contains something we set it as the new search string and
   // initiate search (even though old searches might be in progress).