Web Animations CSS: Add to experimental web platform features

Web Animations CSS: Add to experimental web platform features

This enables use of the Web Animations engine for CSS animations and
transitions when running with experimental web platform features enabled.

It also removes the existing web-animations-css virtual LayoutTests suite
(which ran with --enable-web-animations-css) and replaces it with a new
legacy-animations-engine virtual suite (which runs with
--disable-web-animations-css). Expected results are relocated appropriately.

The change in the expected results for the main animations/ and transitions/
directories document the behavioral progressions introduced by the switch to
the Web Animations engine.

R=dstockwell
BUG=258896, 322272
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=162504

[Steve Block, 2013-11-17 04:33:07]

Note that patchset 3 includes the fix in
https://codereview.chromium.org/73643003, so we can gather meaningful results on
the bots

[dstockwell, 2013-11-17 04:48:45]

On 2013/11/17 04:33:07, Steve Block wrote:
> Note that patchset 3 includes the fix in
> https://codereview.chromium.org/73643003, so we can gather meaningful results
on
> the bots

What do you think about splitting this into three changes?
1. Land the new legacy virtual suite.
2. Flip WebAnimationsCSS to stable
3. Remove the web-animations-css virtual suite

[Steve Block, 2013-11-17 05:09:49]

> What do you think about splitting this into three changes?
What would be the advantage of this? Both steps 1 and 3 would be trivial.

[Steve Block, 2013-11-17 06:33:06]

The latest patch set includes a change to
LayoutTests/fast/css/image-set-value-not-removed-crash-expected.txt which I
don't understand, but which looks benign.

[Steve Block, 2013-11-17 07:11:09]

With the latest patch set, it looks like all failures are due to the missing
compositor integration, as expected.

[dstockwell, 2013-11-17 07:53:22]

On 2013/11/17 05:09:49, Steve Block wrote:
> > What do you think about splitting this into three changes?
> What would be the advantage of this? Both steps 1 and 3 would be trivial.

Right, I think #2 is the only interesting change. This would make it a little
easier for others to see what behavior change is.

[Steve Block, 2013-11-17 22:33:26]

> Right, I think #2 is the only interesting change. This would make it a little
> easier for others to see what behavior change is.
As discussed, this doesn't buy you much. Changes 1 and 3 would simply be 6 line
changes to base.py, so the diff to the expected results in change 2 would be
unaffected. We could copy expected results in change 1, and not remove the stale
expected results until change 3, in an attempt to simplify the diff in change 2,
but this probably adds more complexity that it's worth.

[dstockwell, 2013-11-22 00:58:08]

lgtm

[commit-bot: I haz the power, 2013-11-22 01:02:29]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/steveblock@chromium.org/70903004/730001

[commit-bot: I haz the power, 2013-11-22 01:43:24]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/steveblock@chromium.org/70903004/730001

[commit-bot: I haz the power, 2013-11-22 01:57:03]

Change committed as 162504

[eseidel, 2013-11-22 08:02:59]

I believe this caused a bunch of failures to virtual/threaded, like:
virtual/threaded/transitions/transition-end-event-left.html

garden-o-matic.appspot.com shows many more, but fails to attribute them to this
change.

[dstockwell, 2013-11-22 08:17:42]

On 2013/11/22 08:02:59, eseidel wrote:
> I believe this caused a bunch of failures to virtual/threaded, like:
> virtual/threaded/transitions/transition-end-event-left.html
> 
> http://garden-o-matic.appspot.com shows many more, but fails to attribute them
to this
> change.

The flakiness in virtual/threaded is somewhat expected, we're marking these
flaky and tracking on https://code.google.com/p/chromium/issues/detail?id=322272