This matches patch 2, and also fixes an incorrect use of eRestyle_Self
on the parents of pseudo-elements in order to restyle those
pseudo-elements, where it would not previously have been effective.
This should all be temporary, since this code can go away with bug
960465, when animation phases are removed.
This (like patch 1) posts restyles directly to the pseudo-element
content nodes, which is a new thing as of this bug. Previously we'd
have posted eRestyle_Subtree restyles to the pseudo element's real
element (i.e., the parent of the pseudo-element content node).
This changes the way we post animation restyles for ::before and ::after
pseudo-elements with animations on them.
This (like patch 2) posts restyles directly to the pseudo-element
content nodes, which is a new thing.
This isn't needed right now since AddStyleUpdatesTo is currently only
used when updating main-thread-suppressed animations running on the
compositor. However, it will be needed once we depend on
AddStyleUpdatesTo for bug 960465. And it will have an effect now since
AddStyleUpdatesTo actually adds all animations rather than only the ones
that are suppressed from running on the main thread.
This patch stores the animation name on the Animation object rather than its
AnimationPlayer. This is because Animation objects don't have a reference to
their AnimationPlayer but their AnimationEffect needs access to the animation
name.
This patch also adds an accessor for AnimationPlayer to get the name from its
Animation (since players *do* have a reference to their source animation
content).
This patch fixes a regression from
https://hg.mozilla.org/mozilla-central/rev/31695984cfe2 (bug 1025709). That
patch replaced the EnsureStyleRuleFor method on ElementTransitions and
ElementAnimations with a common method in CommonElementAnimationData.
ElementTransitions::EnsureStyleRuleFor would create a new style rule if
there was no style rule (mStyleRule == nullptr) or if the refresh time was
old (mStyleRuleRefreshTime != aRefreshTime).
ElementAnimations::EnsureStyleRuleFor, however, would create a new style rule
only if mStyleRuleRefreshTime was null or old since a null style rule may
still be valid for animations (unlike transitions). If we bail as soon as we
a null style rule we would never update mNeedsRefreshes when the animation
finishes.
The unified version of EnsureStyleRuleFor in CommonElementAnimationData
adopted the behavior from ElementAnimations checking for a null or old
mStyleRuleRefreshTime.
However, nsTransitionManager::StyleContextChanged sets mStyleRule to nullptr
to indicate that we need to generate a new style rule. This means that we
will fail to create a style rule for the transition in some cases.
This patch addresses this by making nsTransitionManager::StyleContextChanged
set mStyleRuleRefreshTime to a null timestamp. Setting mStyleRule to nullptr
is no longer necessary since EnsureStyleRuleFor will do this when necessary
and nsTransitionManager::mStyleRule is only used after calling
EnsureStyleRuleFor.
With the full patch series, all 4 pairs of tests pass. However, with
patch 10 removed from the patch series, all of the added tests fail
(probably through some interesting interactions).
The second set of 14 tests all fail (both with and without the patch)
because we don't start transitions when the before state is
display:none (either for style contexts coming out of the undisplayed
map or because we have no current style context because an ancestor is
display:none).
The patch makes all of the first set of 14 tests pass. Without the
patch, most of these tests fail, except for the 4 testing e1 and the
root.
I presume the four tests that pass prior to the patch pass because the
restyle actually occurs and starts the transition (which is stored on
the element) before the style context is destroyed.
The assertion in nsTimeStamp::operator >= occasionally fails due to a null RHS
timestamp when called from AnimationPlayer::GetCurrentTimeDuration, which, in
turn, is called from AnimationPlayer::SetSource.
The issue appears to be that we're not correctly initializing
AnimationPlayer.mPlayState. This value can be running (0) or paused (1) but we
only ever compare against the paused state (i.e. every other value is
effectively treated as running). If we don't initialize this we can end
up in the paused state but with mPauseStart not set to a valid (non-null)
TimeStamp. This creates an inconsistent state since we assume that when we're
paused mPauseStart is non-null, hence the assertion fails.
This gets tickled because, since bug 1040543, we call
AnimationPlayer::SetSource from nsAnimationManager::BuildAnimations *before* we
set mPlayState and mPauseStart.
This patch initializes mPlayState to the running state so we don't accidentally
end up in an inconsistent state.
It also removes some (now unnecessary) initialization of mPlayState and
mPauseStart from nsTransitionManager::ConsiderStartingTransition.
In future we could also consider reworking nsAnimationManager::BuildAnimations
so that we call SetSource on the new animation player *after* setting up its
play state. That may be more correct and would further avoid this problem but
may not be necessary since all that code is likely to change in the near future.
This also includes a test that mozMatchesSelector is still exposed and works.
--HG--
rename : js/xpconnect/tests/chrome/test_mozMatchesSelector.xul => js/xpconnect/tests/chrome/test_matches.xul
rename : js/xpconnect/tests/mochitest/file_mozMatchesSelector.html => js/xpconnect/tests/mochitest/file_matches.html
This patch changes the inheritance of ElementPropertyTransition so that it is
a subclass of Animation not AnimationPlayer.
The only thing special about ElementPropertyTransition is it stores some extra
state for reversing transitions and an extra ValuePortionFor convenience method.
This reversing behavior is implemented by the transition manager by creating
a new AnimationPlayer (i.e. it is *not* a property of the AnimationPlayer). As
a result this extra state can be pushed down to Animation which simplifies the
code significantly.
In future if we implement KeyframeEffect as a separate object we may be able to
push transition-specific state down to KeyframeEffect instead.
In this fourth step of dividing functionality between AnimationPlayer and
Animation, we move the mIsLastNotification and related methods/enums from
AnimationPlayer to Animation.
It is somewhat unclear where this belongs. This member is used to determine
which event to send for CSS Animations. The thinking behind moving this to
Animation is that if an animation that has already dispatched its animationstart
event was transferred to a new animation player with a similar current time then
I think it is expected that such an animation would *not* dispatch another
animationstart event. That suggests that event-state is a property of the
Animation not the AnimationPlayer.
Obviously, this needs to be defined somewhere (namely, the CSS Animations <->
Web Animations integration spec likely to become "CSS Animations Level 4"). Once
that behavior is agreed upon, if AnimationPlayer proves to be the more suitable
home for this member then it should be relatively straightforward to move the
member back at that time.
As the third step in dividing functionality between AnimationPlayer and
Animation this patch moves the mIsFinishedTransition member and related methods
from AnimationPlayer to Animation.
At the same time we rename SetFinishedTransition to SetIsFinishedTransition.
