This patch was generated with the following command:
find . -name "*.h" -o -name "*.cpp" | xargs perl -pi -e 's/return ([a-zA-Z0-9]+)\.ErrorCode\(\);/return \1.StealNSResult();/'
Since bug 960465 patch 14, we've retained finished transitions in order
to handle the issues described in
https://lists.w3.org/Archives/Public/www-style/2015Jan/0444.html . The
code that did this made the assumption that the transition manager is
notified of the full sequence of style changes that happen to an
element. However, when an element becomes part of a display:none
subtree and then later becomes displayed again, the transition manager
is not notified of a style change when it becomes displayed again (when
we do not have the old style context).
This patch introduces code to prune the finished transitions when that
happens.
This really fixes only part of the set of problems described in bug
1158431, which also affect running transitions. However, it's the part
of that set that was a regression from bug 960465, which introduced the
retention of finished transitions, and which makes these issues
substantially easier to hit.
I'd like to fix this part quickly because it's a regression and we
should backport the fix.
Without the patch, I confirmed that the following two tests fail:
INFO TEST-UNEXPECTED-FAIL | layout/style/test/test_transitions_dynamic_changes.html | bug 1144410 test - opacity after starting second transition - got 0, expected 1
INFO TEST-UNEXPECTED-FAIL | layout/style/test/test_transitions_dynamic_changes.html | bug 1144410 test - opacity during second transition - got 0, expected 0.5
With the patch, all the added tests pass.
This isn't spec'ed anywhere (since the whole Web Animations API <-> CSS
interaction isn't spec'ed yet) but it seems that changing animation-play-state
should not restart an idle animation.
If an author calls Cancel() on an animation then that animation should continue
to be idle until they call Play()/Pause() from the API. Cancelling an animation
and hanging on to it is a purely API-only feature and hence it's reasonable that
restoring it from this state is also an API-only feature.
One can imagine use-cases such as polyfilling where script wants to remove any
CSS Animations/Transitions run by the browser and replace them with something
else entirely. In that case, the script can call Cancel() on the animation and
be sure that the animation is going to stay out of the way even if something
else tweaks the animation-play-state.
This patch makes Cancel() call PostUpdate which clobbers certain state in style
so that animated style is correctly flushed when an animation is cancelled.
The main difficulty with this is that we *don't* want to call this when we're
cancelling an animation as a result of a style update or else we'll trigger
needless work. The pattern elsewhere has been to define a *FromStyle() method
for this case (e.g. CSSAnimation::PlayFromStyle, PauseFromStyle). This isn't
ideal because there's always the danger we will forget to call the appropriate
*FromStyle method. It is, however, consistent. Hopefully in bug 1151731 we'll
find a better way of expressing this.
Even after this patch, it's not OK to AddRef an ImageValue and then call
Release on its base pointer (URLValue) since URLValue refcounting methods
are not virtual, so it would confuse the leak checker, but at least it
wouldn't cause UAF issues since we'd still be looking at the same mRefCnt
member.
With APZ, we always layerize the first scrollable element of the page,
if the page itself is not scrollable. These additional layers can cause
fuzzy reftest failures in two ways: differences in blending, and by
disabling sub-pixel test anti-aliasing. The latter is only a problem
with unaccelerated drawing, because we don't support component alpha
layers with BasicLayers. (We also don't support them with
BasicCompositor, but "Reftest unaccelerated" only tests BasicLayers).
This avoids accumulating floating point error from conversion, so that
when we switch to doubles at the start of
nsCSSValue::GetAngleValueInRadians we're using the original unit, rather
than a different one that will round differently.
This avoids accumulating floating point error from conversion, so that
when we switch to doubles at the start of
nsCSSValue::GetAngleValueInRadians we're using the original unit, rather
than a different one that will round differently.
In bug 1156456 I landed tests with the transform in radians to work
around float rounding issues with having the transform in degrees. This
bug will fix the problems with degrees, so I'm duplicating the tests
here to have variants with both degrees and radians.
