These tests aim to confirm that part 5 does not cause any regressons.
MozReview-Commit-ID: BtZ1OGiilmQ
--HG--
rename : layout/reftests/css-animations/no-stacking-context-animation-ref.html => layout/reftests/css-transitions/no-stacking-context-transition-ref.html
rename : layout/reftests/css-animations/stacking-context-animation-ref.html => layout/reftests/css-transitions/stacking-context-transition-ref.html
These tests aim to confirm that part 5 does not cause any regressons.
Adding this bunch of reftests makes a slight change in the result of
layout/reftests/bugs/395107-2.html on Android, so fuzzy-if was also
added for the test.
MozReview-Commit-ID: BtZ1OGiilmQ
--HG--
rename : layout/reftests/css-animations/no-stacking-context-animation-ref.html => layout/reftests/css-transitions/no-stacking-context-transition-ref.html
rename : layout/reftests/css-animations/stacking-context-animation-ref.html => layout/reftests/css-transitions/stacking-context-transition-ref.html
We should create a stacking context for any transform or opacity animations
that are either "in effect" (what we currently do) OR "current", i.e.
scheduled to run or running. *BUT* for now, we don't create any stacking
context in before phase without fill:backwards or fill:both because the
property never wins in cascade until the animation gets "in effect". This
restriction will be removed in a subsequent patch in this bug after landing
bug 1279403.
MozReview-Commit-ID: 8RyLJNPtoKI
--HG--
rename : layout/reftests/css-animations/stacking-context-transform-animation-ref.html => layout/reftests/css-animations/stacking-context-animation-ref.html
extra : rebase_source : 0d9c8d9e03ca0d400e9b376b9416fbabffd10034