[android_webview] Fixes for wrap_content layouts.

content/browser/android/content_view_core_impl.h

Index: content/browser/android/content_view_core_impl.h
diff --git a/content/browser/android/content_view_core_impl.h b/content/browser/android/content_view_core_impl.h
index a575907f08ffae13a5cff1239045f1460e5d2666..864eb02efe0fe7381d8e2d49cf797b32bf175aa2 100644
--- a/content/browser/android/content_view_core_impl.h
+++ b/content/browser/android/content_view_core_impl.h
@@ -60,6 +60,8 @@ class ContentViewCoreImpl : public ContentViewCore,
   virtual float GetDpiScale() const OVERRIDE;
   virtual void RequestContentClipping(const gfx::Rect& clipping,
                                       const gfx::Size& content_size) OVERRIDE;
+  virtual void SetViewportSizeDipOverride(
+      const gfx::Size& viewport_size) OVERRIDE;
 
   // --------------------------------------------------------------------------
   // Methods called from Java via JNI
@@ -351,6 +353,10 @@ class ContentViewCoreImpl : public ContentViewCore,
   // Device scale factor.
   float dpi_scale_;
 
+  // This allows for specifying the viewport in DIP pixels directly to avoid
+  // rounding errors.
+  gfx::Size viewport_dip_size_override_;

[aelias_OOO_until_Jul13, 2013/09/06 02:01:35]

I don't like this and it shouldn't be needed.  The intended design with respect
to rounding is that the calculation in GetViewportSizeDip() gives the canonical
width in DIP pixels and every other part of Chrome should use the value produced
there.  By having nobody do the rounding anywhere else, it eliminates the
possibility of off-by-one errors.

It looks like your problem is that some Android WebView code is doing its own
DIP calculation in a different way.  I suggest either making the WebView logic
round the same way or, even better plumb the canonical DIP value from
ContentViewCore to WebView.

[aelias_OOO_until_Jul13, 2013/09/06 02:14:22]

On second thought, I guess it probably has more to do with page scale.

Could you maybe change GetViewportSizeDip() to compute from the physical backing
size that you've already overridden?  For Clank there's no difference between
physical backing size and viewport size.

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

yes and no. The reason I did this is that when the android_webview is to be
sized to exactly match content, we know what the viewport is supposed to be in
DIP pixels but (unless you assume DIP > 1.0) you can't be sure that the physical
size you come up with will be converted back to the right CSS size.

Clank keeps the viewport in physical pixels and then converts it to DIP pixels
by doing the following:
gfx::ToCeiledSize(gfx::ScaleSize(GetViewportSizePix(), 1.0f / GetDpiScale()))

This means that in the AwLayoutSizer we'd have to find a physical size that we
know will result back in the DIP size we want. I don't think that we can do that
for all DIP and size combinations though.

[aelias_OOO_until_Jul13, 2013/09/06 22:27:47]

OK.  I agree you need a way to specify both values independently after all.

+
   // Variables used to keep track of frame timestamps and deadlines.
   base::TimeDelta vsync_interval_;
   base::TimeDelta expected_browser_composite_time_;