Switch the inheritance of WebView from WebWidget to protected.

components/test_runner/test_runner.cc

 // Copyright 2014 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 "components/test_runner/test_runner.h"
 
 #include <stddef.h>
 #include <limits>
 #include <utility>
 
@@ skipping 3093 matching lines @@
 
 void TestRunnerForSpecificView::AddWebPageOverlay() {
   web_view()->setPageOverlayColor(SK_ColorCYAN);
 }
 
 void TestRunnerForSpecificView::RemoveWebPageOverlay() {
   web_view()->setPageOverlayColor(SK_ColorTRANSPARENT);
 }
 
 void TestRunnerForSpecificView::LayoutAndPaintAsync() {
-  test_runner::LayoutAndPaintAsyncThen(web_view(), base::Closure());
+  test_runner::LayoutAndPaintAsyncThen(
+      web_view()->mainFrame()->toWebLocalFrame()->frameWidget(),

[dcheng, 2016/05/03 09:27:13]

I think TestRunnerForSpecificView should actually be TestRunnerForLocalFrame:
then it can just use the associated local frame directly (and will be correct if
called in a cross-process subframe). WDYT of adding a TODO here?

[Łukasz Anforowicz, 2016/05/03 16:09:55]

TestRunnerForSpecificView has some view-specific things - I think we cannot
transition all of its bindings to a TestRunnerForLocalFrame.  Examples of
view-focused bindings:
- SetPageVisibility
- DumpPageImportanceSignals
- Add/RemovePageOverlay
- SetWindowIsKey

OTOH, I agree that it makes sense for a testRunner.layoutAndPaintAsync and
testRunner.layoutAndPaintAsyncThen to target the widget associated with the
frame the javascript bindings are called from.  I am not sure what is the best
way to achieve this:
- Option #1: Store WebLocalFrame* in TestRunnerBindings and pass it to
TestRunnerForSpecificView::LayoutAndPaintAsync method.
- Option #2: Introduce TestRunnerForLocalFrame - owned by WebFrameTestProxyBase.

Option #2 feels more consistent with how other things work (i.e. nothing
currently uses Option #1).

Disclaimer: I have no idea how widget's relationships with frames/views should
look like in the long-term.  Maybe they can be extracted from
WebView/WebTestProxyBase and therefore the current code structure (i.e.
TestRunnerForSpecificView) is okay for the long-term.

[lfg, 2016/05/03 21:19:43]

I think option 1 is similar to how the TestRunnerForSpecificView handles the
animations with an array of WebWidgets that needs to schedule animations.

I agree that option 2 feels more consistent with other things though, but we
would only want to call LayoutAndPaint methods for local roots, so it's not
really something that should exist for every frame.

I think we should really group up all the local frames clustered into a single
local root, and have a runner for that. Not sure how feasible that is, or if
it's worth doing at all.

I'll add a TODO to investigate this issue.

+      base::Closure());
 }
 
 void TestRunnerForSpecificView::LayoutAndPaintAsyncThen(
     v8::Local<v8::Function> callback) {
   test_runner::LayoutAndPaintAsyncThen(
-      web_view(), CreateClosureThatPostsV8Callback(callback));
+      web_view()->mainFrame()->toWebLocalFrame()->frameWidget(),
+      CreateClosureThatPostsV8Callback(callback));
 }
 
 void TestRunnerForSpecificView::GetManifestThen(
     v8::Local<v8::Function> callback) {
   v8::UniquePersistent<v8::Function> persistent_callback(
       blink::mainThreadIsolate(), callback);
 
   delegate()->FetchManifest(
       web_view(), web_view()->mainFrame()->document().manifestURL(),
       base::Bind(&TestRunnerForSpecificView::GetManifestCallback,
@@ skipping 246 matching lines @@
 
 blink::WebView* TestRunnerForSpecificView::web_view() {
   return web_test_proxy_base_->web_view();
 }
 
 WebTestDelegate* TestRunnerForSpecificView::delegate() {
   return web_test_proxy_base_->delegate();
 }
 
 }  // namespace test_runner