Don't calculate a shown ratio when top controls height is 0.

Don't calculate a shown ratio when top controls height is 0.

This was causing a crash in Blink with some Chrome Android UI pages. These
pages would disable top controls by setting the height to 0 but when we
scroll the page we calculate the "shown ratio" by dividing by height. This
the divided-by-0 value made its way down to Blink.

BUG=460007
Committed: https://crrev.com/bfc7eb20e9d2bccc06f16c25d7e95870bbceaa3b
Cr-Commit-Position: refs/heads/master@{#319621}

[bokan, 2015-03-06 19:02:11]

bokan@chromium.org changed reviewers:
+ aelias@chromium.org

[bokan, 2015-03-06 19:04:02]

Alexandre, this is the fix contained in
https://codereview.chromium.org/961023002/. That patch got kicked out due to a
broken layout test. It turns out we activate the funky viewport layer resizing
logic in UpdateViewportContainerSizes with that patch on platforms without top
controls but that do have scrollbars. I'll need to fix that but this fix needs
to make it to 42 so I think it makes sense to land this minimal fix for merging
and reland https://codereview.chromium.org/961023002/ separately.

[aelias_OOO_until_Jul13, 2015-03-06 19:27:26]

lgtm

[bokan, 2015-03-06 20:01:31]

The CQ bit was checked by bokan@chromium.org

[commit-bot: I haz the power, 2015-03-06 20:32:28]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/982333003/1

[aelias_OOO_until_Jul13, 2015-03-06 20:50:20]

So, instead of the aspect ratio calculation in UpdateViewportContainerSizes, I'm
thinking there must be some way to avoid using the width and work purely in
terms of heights, and still get the same result in the Android case.  Something
like this:

float heightRatio = outerViewportContainer->height() /
innerViewportContainer->height();
gfx::Vector2dF delta(0, innerContainer->BoundsDelta() * heightRatio);
outer_container->SetBoundsDelta(delta);
active_tree()->InnerViewportScrollLayer()->SetBoundsDelta(delta);

I probably got something wrong in my math there, but I think some kind of ratio
between heights should work.  If we can avoid using width, then the vertical
non-overlay scrollbars messing with width problem goes away.  Hopefully we can
do the same thing on the Blink side and avoid the similar code behind
Android-specific settings.

[bokan, 2015-03-06 20:53:05]

On 2015/03/06 20:50:20, aelias wrote:
> So, instead of the aspect ratio calculation in UpdateViewportContainerSizes,
I'm
> thinking there must be some way to avoid using the width and work purely in
> terms of heights, and still get the same result in the Android case. 
Something
> like this:
> 
> float heightRatio = outerViewportContainer->height() /
> innerViewportContainer->height();
> gfx::Vector2dF delta(0, innerContainer->BoundsDelta() * heightRatio);
> outer_container->SetBoundsDelta(delta);
> active_tree()->InnerViewportScrollLayer()->SetBoundsDelta(delta);
> 
> I probably got something wrong in my math there, but I think some kind of
ratio
> between heights should work.  If we can avoid using width, then the vertical
> non-overlay scrollbars messing with width problem goes away.  Hopefully we can
> do the same thing on the Blink side and avoid the similar code behind
> Android-specific settings.

I think we'll need to get away from using aspect ratio all together. For
example, the keyboard in CrOS (and eventually Android I think) will change the
size of the inner viewport but not the outer so keeping them the same AR wont
work. I'm pondering how to make this work generally.

[commit-bot: I haz the power, 2015-03-06 23:46:55]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-03-06 23:46:56]

Try jobs failed on following builders:
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_TIMED_OUT, no build URL)
Timed out jobs are not retried to avoid causing additional load on the builders
with large pending queues.

[bokan, 2015-03-09 12:38:27]

The CQ bit was checked by bokan@chromium.org

[commit-bot: I haz the power, 2015-03-09 12:38:38]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/982333003/1

[commit-bot: I haz the power, 2015-03-09 13:41:30]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-03-09 13:42:20]

Patchset 1 (id:??) landed as
https://crrev.com/bfc7eb20e9d2bccc06f16c25d7e95870bbceaa3b
Cr-Commit-Position: refs/heads/master@{#319621}