Set background color when adding a new tab.

chrome/browser/ui/browser.cc

 // Copyright 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "chrome/browser/ui/browser.h"
 
 #include <stddef.h>
 
 #include <algorithm>
 #include <string>
@@ skipping 1023 matching lines @@
   window_->GetLocationBar()->SaveStateToContents(contents);
 
   if (instant_controller_)
     instant_controller_->TabDeactivated(contents);
 }
 
 void Browser::ActiveTabChanged(WebContents* old_contents,
                                WebContents* new_contents,
                                int index,
                                int reason) {
+  // Copies the background color from an old WebContents to a new one that
+  // replaces it on the screen. This allows the new WebContents to use the
+  // old one's background color as the starting background color, before having
+  // loaded any contents. As a result, we avoid flashing white when navigating
+  // from a site whith a dark background to another site with a dark background.
+  if (old_contents && new_contents) {
+    RenderWidgetHostView* old_view = old_contents->GetMainFrame()->GetView();
+    RenderWidgetHostView* new_view = new_contents->GetMainFrame()->GetView();
+    if (old_view && new_view) {

[Peter Kasting, 2017/03/07 00:28:36]

Can this condition actually fail?  When?

Nit: No {}

[chrishtr, 2017/03/07 00:36:48]

I know of no cases. Would you prefer I skip the conditional?
 
Fixed.

[Peter Kasting, 2017/03/07 00:51:20]

My concern is that a null-check implies to future readers that these can be
null.  We should know for sure whether or not these can be null, so we know that
the null-check is definitely needed (and when), and document that, or know that
it's definitely not, so we can omit it or, if necessary, write DCHECKs.

I'm not an expect in WebContents/RenderFrameHost, so I don't know the
constraints here.  But I'm sure someone else does.

[nasko, 2017/03/08 23:11:32]

The GetMainFrame() call is guaranteed to return non-null. However, the call to
GetView() is not. There is a brief period between WebContents creation and the
creation of the RWHV, which if you call GetView() you will get null. I also
think that it happens when the process for the main frame goes away (killed or
crashed).

+      new_view->SetBackgroundColor(old_view->background_color());
+    }
+  }
+
   content::RecordAction(UserMetricsAction("ActiveTabChanged"));
 
   // Update the bookmark state, since the BrowserWindow may query it during
   // OnActiveTabChanged() below.
   UpdateBookmarkBarState(BOOKMARK_BAR_STATE_CHANGE_TAB_SWITCH);
 
   // Let the BrowserWindow do its handling.  On e.g. views this changes the
   // focused object, which should happen before we update the toolbar below,
   // since the omnibox expects the correct element to already be focused when it
   // is updated.
@@ skipping 1622 matching lines @@
     // new window later, thus we need to navigate the window now.
     if (contents) {
       contents->web_contents()->GetController().LoadURL(
           target_url, content::Referrer(), ui::PAGE_TRANSITION_LINK,
           std::string());  // No extra headers.
     }
   }
 
   return contents != NULL;
 }