Bail out of Browser::ScheduleUIUpdate() if the WebContents is stale.

WebContents are not immediate aware they're being deleted, so can still
send updates for a short window between removal from the tabstrip and
deletion. We need to not process updates on stale WebContents objects,
however, and in fact that can cause a crash in TabStripModel.

After some discussion (see attached bug) we have decided to apply this
spot fix and create a longer-term issue to address the underlying cause
(see crbug.com/1007379).

Bug: 993739
Change-Id: Ia16a065edc7bba19f6b1314037e464a43e931c51
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1774959
Commit-Queue: Dana Fried <dfried@chromium.org>
Reviewed-by: Peter Boström <pbos@chromium.org>
Auto-Submit: Dana Fried <dfried@chromium.org>
Cr-Commit-Position: refs/heads/master@{#699578}

chrome/browser/ui/browser.cc

@@ -2297,8 +2297,14 @@ void Browser::UpdateToolbar(bool should_restore_state) {
 
 void Browser::ScheduleUIUpdate(WebContents* source, unsigned changed_flags) {
   DCHECK(source);
-  int index = tab_strip_model_->GetIndexOfWebContents(source);
-  DCHECK_NE(TabStripModel::kNoTab, index);
+  // WebContents may in some rare cases send updates after they've been detached
+  // from the tabstrip but before they are deleted, causing a potential crash if
+  // we proceed. For now bail out.
+  // TODO(crbug.com/1007379) Figure out a safe way to detach browser delegate
+  // from WebContents when it's removed so this doesn't happen - then put a
+  // DCHECK back here.
+  if (tab_strip_model_->GetIndexOfWebContents(source) == TabStripModel::kNoTab)
+    return;
 
   // Do some synchronous updates.
   if (changed_flags & content::INVALIDATE_TYPE_URL) {