Switch the inheritance of WebView from WebWidget to protected.

components/test_runner/test_runner.cc

Index: components/test_runner/test_runner.cc
diff --git a/components/test_runner/test_runner.cc b/components/test_runner/test_runner.cc
index 429bf34a2cfd122d66c0e568c6c060effdad5bfa..2417efc3d4bd4cd9ca69f9548aa9e23692324c6d 100644
--- a/components/test_runner/test_runner.cc
+++ b/components/test_runner/test_runner.cc
@@ -3111,13 +3111,16 @@ void TestRunnerForSpecificView::RemoveWebPageOverlay() {
 }
 
 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(