Added CGFloat comparison functions.

Added CGFloat comparison functions.

Comparing CGFloat values using direct equality was causing flakes in
CRWWebController's PageScrollState unittests, so compare using CGFloat's
epsilon.

BUG=474290
Committed: https://crrev.com/53ce056bd3c312723adca2d3245d75a0599d904c
Cr-Commit-Position: refs/heads/master@{#332223}

[kkhorimoto, 2015-05-21 20:11:30]

kkhorimoto@chromium.org changed reviewers:
+ baxley@chromium.org, eugenebut@chromium.org

[kkhorimoto, 2015-05-21 20:24:01]

kkhorimoto@chromium.org changed reviewers:
+ stuartmorgan@chromium.org

[Eugene But (OOO till 7-30), 2015-05-21 21:13:11]

lgtm with suggestion

https://codereview.chromium.org/1155623002/diff/20001/ios/web/web_state/ui/cr...
File ios/web/web_state/ui/crw_web_controller_unittest.mm (right):

https://codereview.chromium.org/1155623002/diff/20001/ios/web/web_state/ui/cr...
ios/web/web_state/ui/crw_web_controller_unittest.mm:920: return std::fabs(val1 -
val2) < DBL_EPSILON;
Can you use "std::numeric_limits<CGFloat>::epsilon()" to avoid macro?

[kkhorimoto, 2015-05-21 22:07:09]

https://codereview.chromium.org/1155623002/diff/20001/ios/web/web_state/ui/cr...
File ios/web/web_state/ui/crw_web_controller_unittest.mm (right):

https://codereview.chromium.org/1155623002/diff/20001/ios/web/web_state/ui/cr...
ios/web/web_state/ui/crw_web_controller_unittest.mm:920: return std::fabs(val1 -
val2) < DBL_EPSILON;
On 2015/05/21 21:13:11, eugenebut wrote:
> Can you use "std::numeric_limits<CGFloat>::epsilon()" to avoid macro?

Done.

[stuartmorgan, 2015-05-21 22:31:46]

LGTM.

But Eric and I talked about our handling of floats in scrolling code at one
point, and he was under the impression that scroll values were all going to be
fully expressible, and that this shouldn't be a problem.

[kkhorimoto, 2015-05-22 17:22:41]

The CQ bit was checked by kkhorimoto@chromium.org

[kkhorimoto, 2015-05-22 17:22:41]

The patchset sent to the CQ was uploaded after l-g-t-m from
eugenebut@chromium.org
Link to the patchset: https://codereview.chromium.org/1155623002/#ps60001
(title: " ")

[commit-bot: I haz the power, 2015-05-22 17:23:12]

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

[kkhorimoto, 2015-05-22 17:25:09]

On 2015/05/21 22:31:46, stuartmorgan wrote:
> LGTM.
> 
> But Eric and I talked about our handling of floats in scrolling code at one
> point, and he was under the impression that scroll values were all going to be
> fully expressible, and that this shouldn't be a problem.

When investigating flake for these scroll tests, Baxley realized that when the
tests fail, the scroll offset's y coordinate starts at -0 after the initial
rendering of the page, whereas it is normally 0 when it passes.  This leads me
to believe that the wait condition is timing out because of floating point
comparisons; this is a somewhat speculative fix to mitigate some of the flake on
lower-end bots.

[baxley, 2015-05-22 17:42:56]

On 2015/05/22 17:25:09, kkhorimoto_ wrote:
> On 2015/05/21 22:31:46, stuartmorgan wrote:
> > LGTM.
> > 
> > But Eric and I talked about our handling of floats in scrolling code at one
> > point, and he was under the impression that scroll values were all going to
be
> > fully expressible, and that this shouldn't be a problem.
> 
> When investigating flake for these scroll tests, Baxley realized that when the
> tests fail, the scroll offset's y coordinate starts at -0 after the initial
> rendering of the page, whereas it is normally 0 when it passes.  This leads me
> to believe that the wait condition is timing out because of floating point
> comparisons; this is a somewhat speculative fix to mitigate some of the flake
on
> lower-end bots.

Just to clarify, I don't know what the value was when the test started. I
debugged it after it had been stuck at the wait condition (waiting for x == 1)
for a few seconds. At that point the value for x was "-0". I don't know if it
was stuck at -0 from the start, or if it went to 1 and moved on to something
else before reaching the wait condition, or reached some number near 1 and then
returned to -0, or some other possibility.

[commit-bot: I haz the power, 2015-05-22 17:57:56]

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

[commit-bot: I haz the power, 2015-05-22 17:57:57]

Try jobs failed on following builders:
  mac_chromium_compile_dbg_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)

[kkhorimoto, 2015-05-27 22:05:38]

The CQ bit was checked by kkhorimoto@chromium.org

[kkhorimoto, 2015-05-27 22:05:39]

The patchset sent to the CQ was uploaded after l-g-t-m from
stuartmorgan@chromium.org, eugenebut@chromium.org
Link to the patchset: https://codereview.chromium.org/1155623002/#ps100001
(title: " ")

[commit-bot: I haz the power, 2015-05-27 22:08:26]

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

[kkhorimoto, 2015-05-27 22:12:31]

The CQ bit was unchecked by kkhorimoto@chromium.org

[kkhorimoto, 2015-05-27 22:13:20]

kkhorimoto@chromium.org changed reviewers:
+ danakj@chromium.org

[kkhorimoto, 2015-05-27 22:13:21]

+danakj for gfx

[danakj, 2015-05-28 20:59:40]

https://codereview.chromium.org/1155623002/diff/100001/ui/gfx/test/ui_cocoa_t...
File ui/gfx/test/ui_cocoa_test_helper.h (right):

https://codereview.chromium.org/1155623002/diff/100001/ui/gfx/test/ui_cocoa_t...
ui/gfx/test/ui_cocoa_test_helper.h:14: #import "testing/gtest_mac.h"
This is weird, no? Why not just include this at the place that wants to use it?

[kkhorimoto, 2015-05-30 00:29:49]

kkhorimoto@chromium.org changed reviewers:
+ stevenjb@chromium.org

[kkhorimoto, 2015-05-30 00:29:50]

+ stevenjb for tray_view_controller_unittest.mm

https://codereview.chromium.org/1155623002/diff/100001/ui/gfx/test/ui_cocoa_t...
File ui/gfx/test/ui_cocoa_test_helper.h (right):

https://codereview.chromium.org/1155623002/diff/100001/ui/gfx/test/ui_cocoa_t...
ui/gfx/test/ui_cocoa_test_helper.h:14: #import "testing/gtest_mac.h"
On 2015/05/28 20:59:40, danakj wrote:
> This is weird, no? Why not just include this at the place that wants to use
it?

Done.

[stevenjb, 2015-06-01 16:22:24]

rubber stamp lgtm

[danakj, 2015-06-01 16:59:06]

ui/gfx LGTM

[kkhorimoto, 2015-06-01 17:14:26]

The CQ bit was checked by kkhorimoto@chromium.org

[kkhorimoto, 2015-06-01 17:14:26]

The patchset sent to the CQ was uploaded after l-g-t-m from
stuartmorgan@chromium.org, eugenebut@chromium.org
Link to the patchset: https://codereview.chromium.org/1155623002/#ps120001
(title: "Include gtest_mac.h from callers instead of adding it to
ui_cocoa_test_helper.h")

[commit-bot: I haz the power, 2015-06-01 17:15:09]

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

[commit-bot: I haz the power, 2015-06-01 18:18:09]

Committed patchset #7 (id:120001)

[commit-bot: I haz the power, 2015-06-01 18:20:14]

Patchset 7 (id:??) landed as
https://crrev.com/53ce056bd3c312723adca2d3245d75a0599d904c
Cr-Commit-Position: refs/heads/master@{#332223}

[sdefresne, 2015-06-03 07:48:40]

A revert of this CL (patchset #7 id:120001) has been created in
https://codereview.chromium.org/1168523004/ by sdefresne@chromium.org.

The reason for reverting is: Reverting because it cause the downstream waterfall
to be flaky..