[android_webview] Use a fraction to calculate scroll offset.

content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java

Index: content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java
diff --git a/content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java b/content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java
index 88785c177e4d7083df2badb0f07f756141072d1b..b16d8bbe596c4b75af627e029e657298160e3d0d 100644
--- a/content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java
+++ b/content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java
@@ -244,11 +244,9 @@ import java.util.Map;
         /**
          * Called each time any of the parameters are changed.
          *
-         * @param widthCss The content width in logical (CSS) pixels.
-         * @param heightCss The content height in logical (CSS) pixels.
          * @param pageScaleFactor The page scale.
          */
-        void onFrameInfoUpdated(float widthCss, float heightCss, float pageScaleFactor);
+        void onFrameInfoUpdated(float pageScaleFactor);
     }
 
     private VSyncManager.Provider mVSyncProvider;
@@ -2396,9 +2394,8 @@ import java.util.Map;
                 pageScaleFactor, minPageScaleFactor, maxPageScaleFactor,
                 contentOffsetYPix);
 
-        if ((contentSizeChanged || pageScaleChanged) && mUpdateFrameInfoListener != null) {
-            mUpdateFrameInfoListener.onFrameInfoUpdated(
-                    contentWidth, contentHeight, pageScaleFactor);
+        if (pageScaleChanged && mUpdateFrameInfoListener != null) {
+            mUpdateFrameInfoListener.onFrameInfoUpdated(pageScaleFactor);

[aelias_OOO_until_Jul13, 2013/09/24 22:03:19]

Maybe for a separate patch, but it seems to me that if content size came in with
the wrong timing and caused problems, pageScaleFactor would as well.  I suggest
adding a SetPageScaleFactor call to LayerScrollOffsetDelegate and eliminating
this.

[mkosiba (inactive), 2013/09/24 23:18:53]

good spot.

Actually, after thinking about that a bit more: we might want to update
contentSize
before we scroll (so that if the embedder tries to calculate something like
webview.getContentHeight() * webView.getScale() from the onScroll callback they
get current results and not a value lagging 1 frame behind).

Do you think pushing this->children()[0]->bounds(); (taken from
LayerTreeImpl::ScrollableSize)
via the LayerScrollOffsetDelegate be OK? I'm assuming I'd need to do that only
when the
LayerScrollOffsetDelegate is set on a tree (since the layer's sizes change only
on commits).

[aelias_OOO_until_Jul13, 2013/09/24 23:24:27]

In principle it seems fine, but I think you'll get codereview pushback about
examining the child there.

It's been "the plan" for a long time to just set the scroll layer's bounds to
the scrollable size in Blink as well, so we can avoid walking through the tree
structure.  jamesr@ even tried to do that last year but it got reverted because
there was some scenario where it failed to be set correctly.  I'd recommend
fixing that in Blink and using the scroll layer's bounds when you do this.

         }
 
         if (needTemporarilyHideHandles) temporarilyHideTextHandles();