Use consistent background color for WKWebViews.

ios/web/web_state/ui/crw_web_view_content_view.mm

 // Copyright 2015 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.
 
 #import "ios/web/public/web_state/ui/crw_web_view_content_view.h"
 
 #import <WebKit/WebKit.h>
 
 #include "base/logging.h"
 #include "base/mac/scoped_nsobject.h"
 
-namespace {
-
-// Background color RGB values for the content view which is displayed when the
-// |_webView| is offset from the screen due to user interaction. Displaying this
-// background color is handled by UIWebView but not WKWebView, so it needs to be
-// set in CRWWebViewContentView to support both. The color value matches that
-// used by UIWebView.
-const CGFloat kBackgroundRGBComponents[] = {0.75f, 0.74f, 0.76f};
-
-}  // namespace
-
 @interface CRWWebViewContentView () {
   // The web view being shown.
   base::scoped_nsobject<UIView> _webView;
   // The web view's scroll view.
   base::scoped_nsobject<UIScrollView> _scrollView;
   // Backs up property of the same name if |_webView| is a WKWebView.
   CGFloat _topContentPadding;
 }
 
 // Changes web view frame to match |self.bounds| and optionally accomodates for
@@ skipping 35 matching lines @@
   NOTREACHED();
   return nil;
 }
 
 - (void)didMoveToSuperview {
   [super didMoveToSuperview];
   if (self.superview) {
     self.autoresizingMask =
         UIViewAutoresizingFlexibleWidth | UIViewAutoresizingFlexibleHeight;
     [self addSubview:_webView];
-    self.backgroundColor = [UIColor colorWithRed:kBackgroundRGBComponents[0]

[stuartmorgan, 2016/02/11 17:04:34]

Why don't we still need a background color on the content view; are there not
cases where the web view draws what's behind it, rather than itself?

[kkhorimoto, 2016/02/11 18:27:24]

I'm not sure what you mean about the web view drawing what's behind it rather
than itself.  AFAICT, all web rendering occurs in WKContentView, which is one of
the subviews of WKWebView's scroll view.  So if a page is attempting to render a
semi-transparent element, the subview in WKContentView would be transparent, but
the WKWebView's background color will remain constant in the background.  After
inspecting WKWebView's source, it doesn't look like the background color is ever
updated outside of the public UIView API.  It's only the scroll view whose
backgroundColor changes, but since that's a subview of the WKWebView, it should
never show what's behind.

-                                           green:kBackgroundRGBComponents[1]
-                                            blue:kBackgroundRGBComponents[2]
-                                           alpha:1.0];
     // The frame needs to be set immediately after the web view is added
     // as a subview. The change in the frame triggers drawing operations and
     // if not done after it's added as a subview, the web view exhibits
     // strange behavior where clicks from certain web sites are not triggered.
     // The actual value of the frame doesn't matter as long as it's not
     // CGRectZero.  The CRWWebViewContentView's frame will be reset to a correct
     // value in a subsequent layout pass.
     // TODO(crbug.com/577793): This is an undocumented and not-well-understood
     // workaround for this issue.
     const CGRect kDummyRect = CGRectMake(10, 20, 30, 50);
@@ skipping 51 matching lines @@
 
 - (void)updateWebViewFrame {
   CGRect webViewFrame = self.bounds;
   webViewFrame.size.height -= _topContentPadding;
   webViewFrame.origin.y += _topContentPadding;
 
   self.webView.frame = webViewFrame;
 }
 
 @end