Enable newly-imported wpt/web-animations tests.

Enable newly-imported wpt/web-animations tests.

BUG=692105
Review-Url: https://codereview.chromium.org/2708783002
Cr-Commit-Position: refs/heads/master@{#452914}
Committed: https://chromium.googlesource.com/chromium/src/+/1002013da1ecdc443ea0a377994cbcb78ebef5d2

[qyearsley, 2017-02-20 22:55:46]

The CQ bit was checked by qyearsley@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-02-20 22:55:56]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-21 00:04:00]

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

[commit-bot: I haz the power, 2017-02-21 00:04:01]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[qyearsley, 2017-02-23 02:16:32]

The CQ bit was checked by qyearsley@chromium.org to run a CQ dry run

[qyearsley, 2017-02-23 02:16:47]

qyearsley@chromium.org changed reviewers:
+ suzyh@chromium.org

[commit-bot: I haz the power, 2017-02-23 02:17:43]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-23 03:48:20]

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

[commit-bot: I haz the power, 2017-02-23 03:48:21]

Dry run: This issue passed the CQ dry run.

[qyearsley, 2017-02-23 20:30:46]

Hi suzyh@, does this look OK to commit?

[suzyh_UTC10 (ex-contributor), 2017-02-24 00:15:36]

For effect-value-transformed-distance-expected.txt, it looks like there is no
difference between the linux and mac versions, and the only difference between
linux and win is a small (rounding?) difference in two tests: 109.312 vs 109.313
and 9.32812px vs 9.32813px. Do we have an alternative to checking in three
expectations files? I think I would rather have one cross-platform -expected.txt
file and mark Win as FAIL in TestExpectations. If that's absolutely frowned
upon, maybe one cross-platform plus one win-specific -expected.txt file. Has
this sort of problem been encountered anywhere else, to set a precedent for
handling them?

[qyearsley, 2017-02-24 18:10:17]

On 2017/02/24 at 00:15:36, suzyh wrote:
> For effect-value-transformed-distance-expected.txt, it looks like there is no
difference between the linux and mac versions, and the only difference between
linux and win is a small (rounding?) difference in two tests: 109.312 vs 109.313
and 9.32812px vs 9.32813px. Do we have an alternative to checking in three
expectations files? I think I would rather have one cross-platform -expected.txt
file and mark Win as FAIL in TestExpectations. If that's absolutely frowned
upon, maybe one cross-platform plus one win-specific -expected.txt file. Has
this sort of problem been encountered anywhere else, to set a precedent for
handling them?

Yep, checking in one generic and one win expectation should also work!

The reason for why `webkit-patch rebaseline-cl` generated an identical linux and
mac baseline is because the test isn't run on android; and it's "assumed
passing". If the test was also run on android and the result was the same as
mac/linux, then `webkit-patch rebaseline-cl` would have created a generic
baseline and separate windows baseline.

As for whether it's preferred to mark win as FAIL in TestExpectations or have a
platform-specific baseline (-expected.txt), I think that having the
platform-specific baseline has a couple advantages:
 - It records exactly what is different on Windows
 - It is more consistent with what we're doing for all other web-platform-tests.

[suzyh_UTC10 (ex-contributor), 2017-02-24 19:20:40]

On 2017/02/24 at 18:10:17, qyearsley wrote:
> On 2017/02/24 at 00:15:36, suzyh wrote:
> > For effect-value-transformed-distance-expected.txt, it looks like there is
no difference between the linux and mac versions, and the only difference
between linux and win is a small (rounding?) difference in two tests: 109.312 vs
109.313 and 9.32812px vs 9.32813px. Do we have an alternative to checking in
three expectations files? I think I would rather have one cross-platform
-expected.txt file and mark Win as FAIL in TestExpectations. If that's
absolutely frowned upon, maybe one cross-platform plus one win-specific
-expected.txt file. Has this sort of problem been encountered anywhere else, to
set a precedent for handling them?
> 
> Yep, checking in one generic and one win expectation should also work!
> 
> The reason for why `webkit-patch rebaseline-cl` generated an identical linux
and mac baseline is because the test isn't run on android; and it's "assumed
passing". If the test was also run on android and the result was the same as
mac/linux, then `webkit-patch rebaseline-cl` would have created a generic
baseline and separate windows baseline.
> 
> As for whether it's preferred to mark win as FAIL in TestExpectations or have
a platform-specific baseline (-expected.txt), I think that having the
platform-specific baseline has a couple advantages:
>  - It records exactly what is different on Windows
>  - It is more consistent with what we're doing for all other
web-platform-tests.

lgtm, thanks!

[qyearsley, 2017-02-24 19:21:52]

On 2017/02/24 at 18:10:17, qyearsley wrote:
> On 2017/02/24 at 00:15:36, suzyh wrote:
> > For effect-value-transformed-distance-expected.txt, it looks like there is
no difference between the linux and mac versions, and the only difference
between linux and win is a small (rounding?) difference in two tests: 109.312 vs
109.313 and 9.32812px vs 9.32813px. Do we have an alternative to checking in
three expectations files? I think I would rather have one cross-platform
-expected.txt file and mark Win as FAIL in TestExpectations. If that's
absolutely frowned upon, maybe one cross-platform plus one win-specific
-expected.txt file. Has this sort of problem been encountered anywhere else, to
set a precedent for handling them?
> 
> Yep, checking in one generic and one win expectation should also work!
> 
> The reason for why `webkit-patch rebaseline-cl` generated an identical linux
and mac baseline is because the test isn't run on android; and it's "assumed
passing". If the test was also run on android and the result was the same as
mac/linux, then `webkit-patch rebaseline-cl` would have created a generic
baseline and separate windows baseline.

The above is wrong -- I just realized why the set of baselines that was checked
in was checked in, and it's a different but also interesting reason:

If there's no baseline in platform/linux/, then the linux builders fall back to
look in platform/win/ for baselines before looking for generic baselines (but
the same is not true for mac). So in this case, if there's a generic baseline
and windows baseline (as suggested), then linux will fall back to use the
windows baseline, instead of the generic baseline.

Originally, the reason for this was that if linux and win share a lot of
baselines which are different from mac, this means we only have to have a single
file in win/. But conversely, if linux and mac share a baseline that's different
from win, then we have to have duplicates.

[qyearsley, 2017-02-24 19:22:06]

The CQ bit was checked by qyearsley@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-02-24 19:22:29]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[suzyh_UTC10 (ex-contributor), 2017-02-24 19:25:00]

On 2017/02/24 at 19:21:52, qyearsley wrote:
> On 2017/02/24 at 18:10:17, qyearsley wrote:
> > On 2017/02/24 at 00:15:36, suzyh wrote:
> > > For effect-value-transformed-distance-expected.txt, it looks like there is
no difference between the linux and mac versions, and the only difference
between linux and win is a small (rounding?) difference in two tests: 109.312 vs
109.313 and 9.32812px vs 9.32813px. Do we have an alternative to checking in
three expectations files? I think I would rather have one cross-platform
-expected.txt file and mark Win as FAIL in TestExpectations. If that's
absolutely frowned upon, maybe one cross-platform plus one win-specific
-expected.txt file. Has this sort of problem been encountered anywhere else, to
set a precedent for handling them?
> > 
> > Yep, checking in one generic and one win expectation should also work!
> > 
> > The reason for why `webkit-patch rebaseline-cl` generated an identical linux
and mac baseline is because the test isn't run on android; and it's "assumed
passing". If the test was also run on android and the result was the same as
mac/linux, then `webkit-patch rebaseline-cl` would have created a generic
baseline and separate windows baseline.
> 
> The above is wrong -- I just realized why the set of baselines that was
checked in was checked in, and it's a different but also interesting reason:
> 
> If there's no baseline in platform/linux/, then the linux builders fall back
to look in platform/win/ for baselines before looking for generic baselines (but
the same is not true for mac). So in this case, if there's a generic baseline
and windows baseline (as suggested), then linux will fall back to use the
windows baseline, instead of the generic baseline.
> 
> Originally, the reason for this was that if linux and win share a lot of
baselines which are different from mac, this means we only have to have a single
file in win/. But conversely, if linux and mac share a baseline that's different
from win, then we have to have duplicates.

Weird. OK, go ahead with the multiple files then. We'll just have to fix those
two tests so the problem goes away ;)

[qyearsley, 2017-02-24 19:53:06]

The CQ bit was unchecked by qyearsley@chromium.org

[qyearsley, 2017-02-24 19:53:09]

The CQ bit was checked by qyearsley@chromium.org

[qyearsley, 2017-02-24 19:53:09]

The patchset sent to the CQ was uploaded after l-g-t-m from suzyh@chromium.org
Link to the patchset: https://codereview.chromium.org/2708783002/#ps80001
(title: "Revert previous patchset")

[commit-bot: I haz the power, 2017-02-24 19:54:13]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-24 21:09:30]

CQ is committing da patch.

Bot data: {"patchset_id": 80001, "attempt_start_ts": 1487965989119800,
"parent_rev": "908ff1bf9511fe0a66bea48737a898ca71c81440", "commit_rev":
"1002013da1ecdc443ea0a377994cbcb78ebef5d2"}

[commit-bot: I haz the power, 2017-02-24 21:10:09]

Description was changed from

==========
Enable newly-imported wpt/web-animations tests.

BUG=692105
==========

to

==========
Enable newly-imported wpt/web-animations tests.

BUG=692105

Review-Url: https://codereview.chromium.org/2708783002
Cr-Commit-Position: refs/heads/master@{#452914}
Committed:
https://chromium.googlesource.com/chromium/src/+/1002013da1ecdc443ea0a377994c...
==========

[commit-bot: I haz the power, 2017-02-24 21:10:11]

Committed patchset #5 (id:80001) as
https://chromium.googlesource.com/chromium/src/+/1002013da1ecdc443ea0a377994c...