[Android] Use latest page scale factor when computing content width

[Android] Use latest page scale factor when computing content width

Previously, ContentViewCore clamped the effective content bounds from the
compositor frame metadata using the *previous* frame's page scale factor.
Instead, clamp the content bounds using the *current* frame's page scale
factor, and make the content viewport comparison more robust. This fixes an
issue where the content size after page load was being improperly calculated,
preventing mobile sites (e.g., width=device-width) from benefiting from the
disabled tap delay.

BUG=360602
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=262312

[jdduke (slow), 2014-04-07 16:42:51]

johnme@: PTAL.  This resolves the initial double-tap issue we were seeing,
although I haven't been able to reproduce the permanent width=device-width
problem... I wonder if that was on an old Nexus 7? Perhaps the device scale
factor floating issue was at play here?

[jdduke (slow), 2014-04-07 20:32:51]

aelias@: PTAL, looks like I missed johnme@.

[aelias_OOO_until_Jul13, 2014-04-07 21:52:57]

https://codereview.chromium.org/224723019/diff/1/content/public/android/java/...
File
content/public/android/java/src/org/chromium/content/browser/RenderCoordinates.java
(right):

https://codereview.chromium.org/224723019/diff/1/content/public/android/java/...
content/public/android/java/src/org/chromium/content/browser/RenderCoordinates.java:278:
return Math.floor(mContentWidthCss) <= Math.ceil(windowWidthDip);
This seems to be adding a bit of a fudge factor of up to 1px.  What problem are
you correcting for in practice?  For example, if they're within an epsilon of
each other, can we just compare up to that epsilon?

[jdduke (slow), 2014-04-07 21:56:09]

https://codereview.chromium.org/224723019/diff/1/content/public/android/java/...
File
content/public/android/java/src/org/chromium/content/browser/RenderCoordinates.java
(right):

https://codereview.chromium.org/224723019/diff/1/content/public/android/java/...
content/public/android/java/src/org/chromium/content/browser/RenderCoordinates.java:278:
return Math.floor(mContentWidthCss) <= Math.ceil(windowWidthDip);
On 2014/04/07 21:52:57, aelias wrote:
> This seems to be adding a bit of a fudge factor of up to 1px.  What problem
are
> you correcting for in practice?  For example, if they're within an epsilon of
> each other, can we just compare up to that epsilon?

Depending on |mPageScaleFactor|, |windowWidthDip| can be slightly less than an
integral mContentWidthCss.  An epsilon would also work...

[aelias_OOO_until_Jul13, 2014-04-07 22:00:41]

Please switch to an epsilon then, I prefer for the code to be explicit about
when we're compensating for a numerical error.  lgtm otherwise.

[jdduke (slow), 2014-04-07 22:51:33]

The CQ bit was checked by jdduke@chromium.org

[commit-bot: I haz the power, 2014-04-07 22:54:42]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jdduke@chromium.org/224723019/2

[commit-bot: I haz the power, 2014-04-08 04:49:51]

Change committed as 262312