Move content offset to ViewAndroid

content/browser/android/content_view_core_impl.cc

Index: content/browser/android/content_view_core_impl.cc
diff --git a/content/browser/android/content_view_core_impl.cc b/content/browser/android/content_view_core_impl.cc
index bee676ccad0a560288c9ea6fa10aa8d949b1b53b..83c38935d9e3593ac633bff7377b510cad1abced 100644
--- a/content/browser/android/content_view_core_impl.cc
+++ b/content/browser/android/content_view_core_impl.cc
@@ -429,8 +429,7 @@ void ContentViewCoreImpl::UpdateFrameInfo(
   if (obj.is_null() || !view_.GetWindowAndroid())
     return;
 
-  view_.GetWindowAndroid()->set_content_offset(
-      gfx::ScaleVector2d(content_offset, dpi_scale_));
+  view_.set_content_offset(gfx::ScaleVector2d(content_offset, dpi_scale_));

[no sievers, 2016/08/05 18:22:44]

Actually with your change this can now be done in
render_widget_host_view_android.cc instead.

[Jinsuk Kim, 2016/12/22 12:35:48]

Done. BTW I'm not clear about what to do with the content offset of this
view(owned by WebContentsViewAndroid). Shouldn't this be updated in sync with
RWVHA's view content offset?

[boliu, 2016/12/22 21:22:38]

Hmm, debatable.

Ideally, the offset should be on RWHVA only, not WCVA. WCVA should not
contribute to the rendering output (I think?), so no one should try to read from
it should always just delegate to the active RWHVA.

The answer will also depend on how chrome top controls works in the new
ViewAndroid tree world. I'm not sure what the right answer there is.

I think for now, unless there is code that depends on this, let's leave it out
of the WCVA?

 
   page_scale_ = page_scale_factor;