compositor-worker: Add CompositorProxyClient worker client of CompositorWorker.

third_party/WebKit/Source/web/ChromeClientImpl.cpp

Index: third_party/WebKit/Source/web/ChromeClientImpl.cpp
diff --git a/third_party/WebKit/Source/web/ChromeClientImpl.cpp b/third_party/WebKit/Source/web/ChromeClientImpl.cpp
index ab5b0e7b38da10ede99bb915ea7f6405b1e21267..d86f4cc7c2c4de7e5d29cb8dbd61b3cac21637f5 100644
--- a/third_party/WebKit/Source/web/ChromeClientImpl.cpp
+++ b/third_party/WebKit/Source/web/ChromeClientImpl.cpp
@@ -1073,6 +1073,11 @@ void ChromeClientImpl::didUpdateTopControls() const
     m_webView->didUpdateTopControls();
 }
 
+CompositorProxyClient* ChromeClientImpl::createCompositorProxyClient()
+{
+    return m_webView->createCompositorProxyClient();

[dcheng, 2016/05/12 16:56:15]

Why does this have to go through WebView? Why can't this just new
CompositorProxyClient directly?

[flackr, 2016/05/12 17:00:51]

In this patch it absolutely could - I can move it there for this patch. In
https://codereview.chromium.org/1895873006 when we hook it up to the
CompositorMutatorImpl we need WebViewImpl to pass the constructed
CompositorMutatorImpl through WebLayerTreeView to the LayerTreeHostImpl.

[dcheng, 2016/05/12 17:09:29]

I don't think that patch will work well with OOPI: the WebView won't have a
WebLayerTreeView if the main frame is a remote frame. Maybe it should be plumbed
through WebFrameWidget instead (we'll likely need to special case the main frame
case to fall back to WebViewImpl for now, since we're still in the process of
factoring out the WebWidget portions of WebView).

+}
+
 void ChromeClientImpl::registerPopupOpeningObserver(PopupOpeningObserver* observer)
 {
     DCHECK(observer);