2011-04-12 10:18:44 +04:00
|
|
|
/* vim: set shiftwidth=2 tabstop=8 autoindent cindent expandtab: */
|
2012-05-21 15:12:37 +04:00
|
|
|
/* This Source Code Form is subject to the terms of the Mozilla Public
|
|
|
|
* License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
|
|
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
|
2011-04-12 10:18:44 +04:00
|
|
|
|
|
|
|
#include "nsAnimationManager.h"
|
2013-10-22 16:14:41 +04:00
|
|
|
#include "nsTransitionManager.h"
|
2015-06-30 04:00:39 +03:00
|
|
|
#include "mozilla/dom/CSSAnimationBinding.h"
|
2013-06-30 20:26:39 +04:00
|
|
|
|
2016-01-06 05:04:04 +03:00
|
|
|
#include "mozilla/EffectCompositor.h"
|
2013-06-30 20:26:39 +04:00
|
|
|
#include "mozilla/MemoryReporting.h"
|
2014-06-24 10:29:54 +04:00
|
|
|
#include "mozilla/StyleAnimationValue.h"
|
2015-04-28 05:29:13 +03:00
|
|
|
#include "mozilla/dom/DocumentTimeline.h"
|
2015-04-15 02:48:21 +03:00
|
|
|
#include "mozilla/dom/KeyframeEffect.h"
|
2013-06-30 20:26:39 +04:00
|
|
|
|
2011-04-12 10:18:44 +04:00
|
|
|
#include "nsPresContext.h"
|
|
|
|
#include "nsStyleSet.h"
|
2013-10-22 16:14:41 +04:00
|
|
|
#include "nsStyleChangeList.h"
|
2011-04-12 10:18:44 +04:00
|
|
|
#include "nsCSSRules.h"
|
2013-10-22 16:14:41 +04:00
|
|
|
#include "RestyleManager.h"
|
2013-06-18 15:41:30 +04:00
|
|
|
#include "nsLayoutUtils.h"
|
2013-10-01 01:26:04 +04:00
|
|
|
#include "nsIFrame.h"
|
2013-10-03 00:09:18 +04:00
|
|
|
#include "nsIDocument.h"
|
2015-03-14 08:34:40 +03:00
|
|
|
#include "nsDOMMutationObserver.h"
|
2013-01-11 09:14:51 +04:00
|
|
|
#include <math.h>
|
2011-04-12 10:18:44 +04:00
|
|
|
|
|
|
|
using namespace mozilla;
|
2012-08-22 05:48:47 +04:00
|
|
|
using namespace mozilla::css;
|
2015-04-21 04:22:09 +03:00
|
|
|
using mozilla::dom::Animation;
|
2015-04-27 02:53:19 +03:00
|
|
|
using mozilla::dom::AnimationPlayState;
|
2015-04-30 16:06:43 +03:00
|
|
|
using mozilla::dom::KeyframeEffectReadOnly;
|
2015-06-30 04:00:39 +03:00
|
|
|
using mozilla::dom::CSSAnimation;
|
|
|
|
|
2015-07-29 04:57:39 +03:00
|
|
|
////////////////////////// CSSAnimation ////////////////////////////
|
|
|
|
|
2015-06-30 04:00:39 +03:00
|
|
|
JSObject*
|
|
|
|
CSSAnimation::WrapObject(JSContext* aCx, JS::Handle<JSObject*> aGivenProto)
|
|
|
|
{
|
|
|
|
return dom::CSSAnimationBinding::Wrap(aCx, this, aGivenProto);
|
|
|
|
}
|
2011-04-12 10:18:44 +04:00
|
|
|
|
2014-12-18 02:42:41 +03:00
|
|
|
mozilla::dom::Promise*
|
2015-04-21 04:22:10 +03:00
|
|
|
CSSAnimation::GetReady(ErrorResult& aRv)
|
2014-12-18 02:42:41 +03:00
|
|
|
{
|
|
|
|
FlushStyle();
|
2015-04-21 04:22:09 +03:00
|
|
|
return Animation::GetReady(aRv);
|
2014-12-18 02:42:41 +03:00
|
|
|
}
|
|
|
|
|
2014-10-20 08:55:46 +04:00
|
|
|
void
|
2015-05-19 08:00:48 +03:00
|
|
|
CSSAnimation::Play(ErrorResult &aRv, LimitBehavior aLimitBehavior)
|
2014-10-20 08:55:46 +04:00
|
|
|
{
|
|
|
|
mPauseShouldStick = false;
|
2015-05-19 08:00:48 +03:00
|
|
|
Animation::Play(aRv, aLimitBehavior);
|
2014-10-20 08:55:46 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
2015-05-19 08:55:26 +03:00
|
|
|
CSSAnimation::Pause(ErrorResult& aRv)
|
2014-10-20 08:55:46 +04:00
|
|
|
{
|
|
|
|
mPauseShouldStick = true;
|
2015-05-19 08:55:26 +03:00
|
|
|
Animation::Pause(aRv);
|
2014-10-20 08:55:46 +04:00
|
|
|
}
|
|
|
|
|
2015-04-27 02:53:19 +03:00
|
|
|
AnimationPlayState
|
2015-04-21 04:22:10 +03:00
|
|
|
CSSAnimation::PlayStateFromJS() const
|
2014-11-17 07:45:58 +03:00
|
|
|
{
|
|
|
|
// Flush style to ensure that any properties controlling animation state
|
|
|
|
// (e.g. animation-play-state) are fully updated.
|
|
|
|
FlushStyle();
|
2015-04-21 04:22:09 +03:00
|
|
|
return Animation::PlayStateFromJS();
|
2014-11-17 07:45:58 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
2015-05-19 08:00:48 +03:00
|
|
|
CSSAnimation::PlayFromJS(ErrorResult& aRv)
|
2014-11-17 07:45:58 +03:00
|
|
|
{
|
|
|
|
// Note that flushing style below might trigger calls to
|
|
|
|
// PlayFromStyle()/PauseFromStyle() on this object.
|
|
|
|
FlushStyle();
|
2015-05-19 08:00:48 +03:00
|
|
|
Animation::PlayFromJS(aRv);
|
2014-11-17 07:45:58 +03:00
|
|
|
}
|
|
|
|
|
2014-10-20 08:55:46 +04:00
|
|
|
void
|
2015-04-21 04:22:10 +03:00
|
|
|
CSSAnimation::PlayFromStyle()
|
2014-10-20 08:55:46 +04:00
|
|
|
{
|
|
|
|
mIsStylePaused = false;
|
|
|
|
if (!mPauseShouldStick) {
|
2015-05-19 08:00:48 +03:00
|
|
|
ErrorResult rv;
|
|
|
|
DoPlay(rv, Animation::LimitBehavior::Continue);
|
|
|
|
// play() should not throw when LimitBehavior is Continue
|
|
|
|
MOZ_ASSERT(!rv.Failed(), "Unexpected exception playing animation");
|
2014-10-20 08:55:46 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
2015-04-21 04:22:10 +03:00
|
|
|
CSSAnimation::PauseFromStyle()
|
2014-10-20 08:55:46 +04:00
|
|
|
{
|
|
|
|
// Check if the pause state is being overridden
|
|
|
|
if (mIsStylePaused) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
mIsStylePaused = true;
|
2015-05-19 08:55:26 +03:00
|
|
|
ErrorResult rv;
|
|
|
|
DoPause(rv);
|
|
|
|
// pause() should only throw when *all* of the following conditions are true:
|
|
|
|
// - we are in the idle state, and
|
|
|
|
// - we have a negative playback rate, and
|
|
|
|
// - we have an infinitely repeating animation
|
|
|
|
// The first two conditions will never happen under regular style processing
|
|
|
|
// but could happen if an author made modifications to the Animation object
|
|
|
|
// and then updated animation-play-state. It's an unusual case and there's
|
|
|
|
// no obvious way to pass on the exception information so we just silently
|
|
|
|
// fail for now.
|
|
|
|
if (rv.Failed()) {
|
|
|
|
NS_WARNING("Unexpected exception pausing animation - silently failing");
|
|
|
|
}
|
2014-10-20 08:55:46 +04:00
|
|
|
}
|
|
|
|
|
2015-07-29 04:57:39 +03:00
|
|
|
void
|
|
|
|
CSSAnimation::Tick()
|
|
|
|
{
|
|
|
|
Animation::Tick();
|
|
|
|
QueueEvents();
|
|
|
|
}
|
|
|
|
|
2015-06-09 05:13:54 +03:00
|
|
|
bool
|
|
|
|
CSSAnimation::HasLowerCompositeOrderThan(const Animation& aOther) const
|
|
|
|
{
|
|
|
|
// 0. Object-equality case
|
|
|
|
if (&aOther == this) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// 1. Transitions sort lower
|
|
|
|
//
|
|
|
|
// FIXME: We need to differentiate between transitions and generic Animations.
|
|
|
|
// Generic animations don't exist yet (that's bug 1096773) so for now we're
|
|
|
|
// ok.
|
|
|
|
const CSSAnimation* otherAnimation = aOther.AsCSSAnimation();
|
|
|
|
if (!otherAnimation) {
|
|
|
|
MOZ_ASSERT(aOther.AsCSSTransition(),
|
|
|
|
"Animation being compared is a CSS transition");
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2015-09-15 07:32:12 +03:00
|
|
|
// 2. CSS animations that correspond to an animation-name property sort lower
|
|
|
|
// than other CSS animations (e.g. those created or kept-alive by script).
|
|
|
|
if (!IsTiedToMarkup()) {
|
|
|
|
return !otherAnimation->IsTiedToMarkup() ?
|
2015-06-09 05:13:54 +03:00
|
|
|
Animation::HasLowerCompositeOrderThan(aOther) :
|
|
|
|
false;
|
|
|
|
}
|
2015-09-15 07:32:12 +03:00
|
|
|
if (!otherAnimation->IsTiedToMarkup()) {
|
2015-06-09 05:13:54 +03:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
// 3. Sort by document order
|
2015-09-15 05:20:33 +03:00
|
|
|
if (!mOwningElement.Equals(otherAnimation->mOwningElement)) {
|
|
|
|
return mOwningElement.LessThan(otherAnimation->mOwningElement);
|
2015-06-09 05:13:54 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
// 4. (Same element and pseudo): Sort by position in animation-name
|
2015-09-15 05:20:26 +03:00
|
|
|
return mAnimationIndex < otherAnimation->mAnimationIndex;
|
2015-06-09 05:13:54 +03:00
|
|
|
}
|
|
|
|
|
2014-10-20 08:55:47 +04:00
|
|
|
void
|
2015-07-29 04:57:39 +03:00
|
|
|
CSSAnimation::QueueEvents()
|
2014-10-20 08:55:47 +04:00
|
|
|
{
|
2015-04-15 02:48:21 +03:00
|
|
|
if (!mEffect) {
|
2014-10-20 08:55:47 +04:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-07-29 04:57:39 +03:00
|
|
|
// CSS animations dispatch events at their owning element. This allows
|
|
|
|
// script to repurpose a CSS animation to target a different element,
|
|
|
|
// to use a group effect (which has no obvious "target element"), or
|
|
|
|
// to remove the animation effect altogether whilst still getting
|
|
|
|
// animation events.
|
|
|
|
//
|
|
|
|
// It does mean, however, that for a CSS animation that has no owning
|
|
|
|
// element (e.g. it was created using the CSSAnimation constructor or
|
|
|
|
// disassociated from CSS) no events are fired. If it becomes desirable
|
|
|
|
// for these animations to still fire events we should spec the concept
|
|
|
|
// of the "original owning element" or "event target" and allow script
|
|
|
|
// to set it when creating a CSSAnimation object.
|
|
|
|
if (!mOwningElement.IsSet()) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
dom::Element* owningElement;
|
|
|
|
nsCSSPseudoElements::Type owningPseudoType;
|
|
|
|
mOwningElement.GetElement(owningElement, owningPseudoType);
|
|
|
|
MOZ_ASSERT(owningElement, "Owning element should be set");
|
|
|
|
|
|
|
|
// Get the nsAnimationManager so we can queue events on it
|
|
|
|
nsPresContext* presContext = mOwningElement.GetRenderedPresContext();
|
|
|
|
if (!presContext) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
nsAnimationManager* manager = presContext->AnimationManager();
|
|
|
|
|
2015-04-15 02:48:21 +03:00
|
|
|
ComputedTiming computedTiming = mEffect->GetComputedTiming();
|
2014-10-20 08:55:47 +04:00
|
|
|
|
2015-10-19 01:38:00 +03:00
|
|
|
if (computedTiming.mPhase == ComputedTiming::AnimationPhase::Null) {
|
2015-02-13 18:58:33 +03:00
|
|
|
return; // do nothing
|
|
|
|
}
|
|
|
|
|
|
|
|
// Note that script can change the start time, so we have to handle moving
|
|
|
|
// backwards through the animation as well as forwards. An 'animationstart'
|
|
|
|
// is dispatched if we enter the active phase (regardless if that is from
|
|
|
|
// before or after the animation's active phase). An 'animationend' is
|
|
|
|
// dispatched if we leave the active phase (regardless if that is to before
|
|
|
|
// or after the animation's active phase).
|
|
|
|
|
|
|
|
bool wasActive = mPreviousPhaseOrIteration != PREVIOUS_PHASE_BEFORE &&
|
|
|
|
mPreviousPhaseOrIteration != PREVIOUS_PHASE_AFTER;
|
|
|
|
bool isActive =
|
2015-10-19 01:38:00 +03:00
|
|
|
computedTiming.mPhase == ComputedTiming::AnimationPhase::Active;
|
2015-02-13 18:58:33 +03:00
|
|
|
bool isSameIteration =
|
|
|
|
computedTiming.mCurrentIteration == mPreviousPhaseOrIteration;
|
|
|
|
bool skippedActivePhase =
|
|
|
|
(mPreviousPhaseOrIteration == PREVIOUS_PHASE_BEFORE &&
|
2015-10-19 01:38:00 +03:00
|
|
|
computedTiming.mPhase == ComputedTiming::AnimationPhase::After) ||
|
2015-02-13 18:58:33 +03:00
|
|
|
(mPreviousPhaseOrIteration == PREVIOUS_PHASE_AFTER &&
|
2015-10-19 01:38:00 +03:00
|
|
|
computedTiming.mPhase == ComputedTiming::AnimationPhase::Before);
|
2015-02-13 18:58:33 +03:00
|
|
|
|
|
|
|
MOZ_ASSERT(!skippedActivePhase || (!isActive && !wasActive),
|
|
|
|
"skippedActivePhase only makes sense if we were & are inactive");
|
|
|
|
|
2015-10-19 01:38:00 +03:00
|
|
|
if (computedTiming.mPhase == ComputedTiming::AnimationPhase::Before) {
|
2015-02-13 18:58:33 +03:00
|
|
|
mPreviousPhaseOrIteration = PREVIOUS_PHASE_BEFORE;
|
2015-10-19 01:38:00 +03:00
|
|
|
} else if (computedTiming.mPhase == ComputedTiming::AnimationPhase::Active) {
|
2015-02-13 18:58:33 +03:00
|
|
|
mPreviousPhaseOrIteration = computedTiming.mCurrentIteration;
|
2015-10-19 01:38:00 +03:00
|
|
|
} else if (computedTiming.mPhase == ComputedTiming::AnimationPhase::After) {
|
2015-02-13 18:58:33 +03:00
|
|
|
mPreviousPhaseOrIteration = PREVIOUS_PHASE_AFTER;
|
|
|
|
}
|
|
|
|
|
2015-08-26 15:56:59 +03:00
|
|
|
EventMessage message;
|
2015-02-13 18:58:33 +03:00
|
|
|
|
|
|
|
if (!wasActive && isActive) {
|
2015-09-10 19:59:53 +03:00
|
|
|
message = eAnimationStart;
|
2015-02-13 18:58:33 +03:00
|
|
|
} else if (wasActive && !isActive) {
|
2015-09-10 19:59:53 +03:00
|
|
|
message = eAnimationEnd;
|
2015-02-13 18:58:33 +03:00
|
|
|
} else if (wasActive && isActive && !isSameIteration) {
|
2015-09-10 19:59:53 +03:00
|
|
|
message = eAnimationIteration;
|
2015-02-13 18:58:33 +03:00
|
|
|
} else if (skippedActivePhase) {
|
|
|
|
// First notifying for start of 0th iteration by appending an
|
|
|
|
// 'animationstart':
|
|
|
|
StickyTimeDuration elapsedTime =
|
2015-09-15 08:03:24 +03:00
|
|
|
std::min(StickyTimeDuration(InitialAdvance()),
|
2015-02-13 18:58:33 +03:00
|
|
|
computedTiming.mActiveDuration);
|
2015-09-15 08:04:05 +03:00
|
|
|
manager->QueueEvent(AnimationEventInfo(owningElement, owningPseudoType,
|
|
|
|
eAnimationStart, mAnimationName,
|
2015-09-15 08:04:53 +03:00
|
|
|
elapsedTime,
|
2015-09-15 08:05:44 +03:00
|
|
|
ElapsedTimeToTimeStamp(elapsedTime),
|
|
|
|
this));
|
2015-02-13 18:58:33 +03:00
|
|
|
// Then have the shared code below append an 'animationend':
|
2015-09-10 19:59:53 +03:00
|
|
|
message = eAnimationEnd;
|
2015-02-13 18:58:33 +03:00
|
|
|
} else {
|
|
|
|
return; // No events need to be sent
|
2014-10-20 08:55:47 +04:00
|
|
|
}
|
2015-02-13 18:58:33 +03:00
|
|
|
|
|
|
|
StickyTimeDuration elapsedTime;
|
|
|
|
|
2015-09-10 19:59:53 +03:00
|
|
|
if (message == eAnimationStart || message == eAnimationIteration) {
|
2015-04-15 02:48:21 +03:00
|
|
|
TimeDuration iterationStart = mEffect->Timing().mIterationDuration *
|
2015-02-13 18:58:33 +03:00
|
|
|
computedTiming.mCurrentIteration;
|
|
|
|
elapsedTime = StickyTimeDuration(std::max(iterationStart,
|
2015-09-15 08:03:24 +03:00
|
|
|
InitialAdvance()));
|
2015-02-13 18:58:33 +03:00
|
|
|
} else {
|
2015-09-10 19:59:53 +03:00
|
|
|
MOZ_ASSERT(message == eAnimationEnd);
|
2015-02-13 18:58:33 +03:00
|
|
|
elapsedTime = computedTiming.mActiveDuration;
|
|
|
|
}
|
|
|
|
|
2015-09-15 08:04:05 +03:00
|
|
|
manager->QueueEvent(AnimationEventInfo(owningElement, owningPseudoType,
|
2015-09-15 08:04:53 +03:00
|
|
|
message, mAnimationName, elapsedTime,
|
2015-09-15 08:05:44 +03:00
|
|
|
ElapsedTimeToTimeStamp(elapsedTime),
|
|
|
|
this));
|
2014-10-20 08:55:47 +04:00
|
|
|
}
|
|
|
|
|
2014-11-17 07:45:58 +03:00
|
|
|
CommonAnimationManager*
|
2015-04-21 04:22:10 +03:00
|
|
|
CSSAnimation::GetAnimationManager() const
|
2014-11-17 07:45:58 +03:00
|
|
|
{
|
|
|
|
nsPresContext* context = GetPresContext();
|
|
|
|
if (!context) {
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
return context->AnimationManager();
|
|
|
|
}
|
|
|
|
|
2015-09-15 05:20:56 +03:00
|
|
|
void
|
|
|
|
CSSAnimation::UpdateTiming(SeekFlag aSeekFlag, SyncNotifyFlag aSyncNotifyFlag)
|
|
|
|
{
|
|
|
|
if (mNeedsNewAnimationIndexWhenRun &&
|
|
|
|
PlayState() != AnimationPlayState::Idle) {
|
|
|
|
mAnimationIndex = sNextAnimationIndex++;
|
|
|
|
mNeedsNewAnimationIndexWhenRun = false;
|
|
|
|
}
|
|
|
|
|
|
|
|
Animation::UpdateTiming(aSeekFlag, aSyncNotifyFlag);
|
|
|
|
}
|
|
|
|
|
2015-09-15 08:04:08 +03:00
|
|
|
TimeStamp
|
|
|
|
CSSAnimation::ElapsedTimeToTimeStamp(const StickyTimeDuration&
|
|
|
|
aElapsedTime) const
|
|
|
|
{
|
|
|
|
// Initializes to null. We always return this object to benefit from
|
|
|
|
// return-value-optimization.
|
|
|
|
TimeStamp result;
|
|
|
|
|
|
|
|
// Currently we may dispatch animationstart events before resolving
|
|
|
|
// mStartTime if we have a delay <= 0. This will change in bug 1134163
|
|
|
|
// but until then we should just use the latest refresh driver time as
|
|
|
|
// the event timestamp in that case.
|
|
|
|
if (!mEffect || mStartTime.IsNull()) {
|
|
|
|
nsPresContext* presContext = GetPresContext();
|
|
|
|
if (presContext) {
|
|
|
|
result = presContext->RefreshDriver()->MostRecentRefresh();
|
|
|
|
}
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
result = AnimationTimeToTimeStamp(aElapsedTime + mEffect->Timing().mDelay);
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
2015-07-29 04:57:39 +03:00
|
|
|
////////////////////////// nsAnimationManager ////////////////////////////
|
|
|
|
|
2015-07-29 04:57:39 +03:00
|
|
|
NS_IMPL_CYCLE_COLLECTION(nsAnimationManager, mEventDispatcher)
|
2015-07-29 04:57:39 +03:00
|
|
|
|
|
|
|
NS_IMPL_CYCLE_COLLECTING_ADDREF(nsAnimationManager)
|
|
|
|
NS_IMPL_CYCLE_COLLECTING_RELEASE(nsAnimationManager)
|
|
|
|
|
|
|
|
NS_INTERFACE_MAP_BEGIN_CYCLE_COLLECTION(nsAnimationManager)
|
|
|
|
NS_INTERFACE_MAP_ENTRY(nsIStyleRuleProcessor)
|
|
|
|
NS_INTERFACE_MAP_ENTRY_AMBIGUOUS(nsISupports, nsIStyleRuleProcessor)
|
|
|
|
NS_INTERFACE_MAP_END
|
|
|
|
|
2015-04-01 01:05:54 +03:00
|
|
|
void
|
2015-04-21 04:22:10 +03:00
|
|
|
nsAnimationManager::MaybeUpdateCascadeResults(AnimationCollection* aCollection)
|
2015-04-01 01:05:54 +03:00
|
|
|
{
|
2015-04-21 04:22:10 +03:00
|
|
|
for (size_t animIdx = aCollection->mAnimations.Length(); animIdx-- != 0; ) {
|
2015-04-21 04:22:10 +03:00
|
|
|
CSSAnimation* anim = aCollection->mAnimations[animIdx]->AsCSSAnimation();
|
2015-04-21 04:22:10 +03:00
|
|
|
if (anim->IsInEffect() != anim->mInEffectForCascadeResults) {
|
2015-04-01 01:05:54 +03:00
|
|
|
// Update our own cascade results.
|
2015-04-01 01:05:54 +03:00
|
|
|
mozilla::dom::Element* element = aCollection->GetElementToRestyle();
|
2015-05-22 07:46:26 +03:00
|
|
|
bool updatedCascadeResults = false;
|
2015-04-01 01:05:54 +03:00
|
|
|
if (element) {
|
|
|
|
nsIFrame* frame = element->GetPrimaryFrame();
|
|
|
|
if (frame) {
|
|
|
|
UpdateCascadeResults(frame->StyleContext(), aCollection);
|
2015-05-22 07:46:26 +03:00
|
|
|
updatedCascadeResults = true;
|
2015-04-01 01:05:54 +03:00
|
|
|
}
|
|
|
|
}
|
2015-04-01 01:05:54 +03:00
|
|
|
|
2015-05-22 07:46:26 +03:00
|
|
|
if (!updatedCascadeResults) {
|
|
|
|
// If we don't have a style context we can't do the work of updating
|
|
|
|
// cascading results but we need to make sure to update
|
|
|
|
// mInEffectForCascadeResults or else we'll keep running this
|
|
|
|
// code every time (potentially leading to infinite recursion due
|
|
|
|
// to the fact that this method both calls and is (indirectly) called
|
|
|
|
// by nsTransitionManager).
|
|
|
|
anim->mInEffectForCascadeResults = anim->IsInEffect();
|
|
|
|
}
|
|
|
|
|
2015-04-01 01:05:54 +03:00
|
|
|
// Notify the transition manager, whose results might depend on ours.
|
|
|
|
mPresContext->TransitionManager()->
|
|
|
|
UpdateCascadeResultsWithAnimations(aCollection);
|
|
|
|
|
2015-04-01 01:05:54 +03:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-12-09 09:01:52 +04:00
|
|
|
/* virtual */ size_t
|
2013-06-23 16:03:39 +04:00
|
|
|
nsAnimationManager::SizeOfExcludingThis(MallocSizeOf aMallocSizeOf) const
|
2011-12-09 09:01:52 +04:00
|
|
|
{
|
|
|
|
return CommonAnimationManager::SizeOfExcludingThis(aMallocSizeOf);
|
2012-01-03 06:19:14 +04:00
|
|
|
|
|
|
|
// Measurement of the following members may be added later if DMD finds it is
|
|
|
|
// worthwhile:
|
2015-07-29 04:57:39 +03:00
|
|
|
// - mEventDispatcher
|
2011-12-09 09:01:52 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
/* virtual */ size_t
|
2013-06-23 16:03:39 +04:00
|
|
|
nsAnimationManager::SizeOfIncludingThis(MallocSizeOf aMallocSizeOf) const
|
2011-12-09 09:01:52 +04:00
|
|
|
{
|
2012-01-25 12:52:51 +04:00
|
|
|
return aMallocSizeOf(this) + SizeOfExcludingThis(aMallocSizeOf);
|
2011-12-09 09:01:52 +04:00
|
|
|
}
|
|
|
|
|
2015-12-20 16:17:00 +03:00
|
|
|
void
|
|
|
|
nsAnimationManager::CopyIsRunningOnCompositor(
|
|
|
|
KeyframeEffectReadOnly& aSourceEffect,
|
|
|
|
KeyframeEffectReadOnly& aDestEffect)
|
|
|
|
{
|
|
|
|
nsCSSPropertySet sourceProperties;
|
|
|
|
|
|
|
|
for (AnimationProperty& property : aSourceEffect.Properties()) {
|
|
|
|
if (property.mIsRunningOnCompositor) {
|
|
|
|
sourceProperties.AddProperty(property.mProperty);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
for (AnimationProperty& property : aDestEffect.Properties()) {
|
|
|
|
if (sourceProperties.HasProperty(property.mProperty)) {
|
|
|
|
property.mIsRunningOnCompositor = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-04-12 10:18:44 +04:00
|
|
|
nsIStyleRule*
|
|
|
|
nsAnimationManager::CheckAnimationRule(nsStyleContext* aStyleContext,
|
|
|
|
mozilla::dom::Element* aElement)
|
|
|
|
{
|
2015-09-09 04:10:41 +03:00
|
|
|
// Ignore animations for print or print preview, and for elements
|
|
|
|
// that are not attached to the document tree.
|
|
|
|
if (!mPresContext->IsDynamic() || !aElement->IsInComposedDoc()) {
|
Bug 960465 patch 17 - Remove separate animation and non-animation phases of restyling. r=birtles
Note that this means that when we start transitions, we post restyles
that are processed during the current restyling operation, rather than
in a later phase. This depends on patch 11, which makes the transition
manager skip style changes that it posts while starting transitions, to
ensure that this doesn't lead to an infinite loop. This also depends on
patch 16, which only consumes restyle data for the primary frame, to
ensure that the animation restyles posted are processed properly. It
also depends on patch 14, which makes us retain data on finished
transitions, to avoid triggering extra transitions on descendants when
both an ancestor and a descendant transition an inherited property, and
the descendant does so faster.
This fixes a known failure in layout/style/test/test_animations.html and
test_animations_omta.html (as visible in the patch). I believe this is
because this patch changes us to compute keyframe values for animations
on top of a style context *with* animation data rather than one without,
which means what we're computing them on top of changes each time. (The
purpose of patch 3 was to avoid this in the case where avoiding it
matters, i.e., implicit 0% and 100% keyframes.)
2015-02-17 01:15:05 +03:00
|
|
|
return nullptr;
|
|
|
|
}
|
2011-04-12 10:18:44 +04:00
|
|
|
|
Bug 960465 patch 17 - Remove separate animation and non-animation phases of restyling. r=birtles
Note that this means that when we start transitions, we post restyles
that are processed during the current restyling operation, rather than
in a later phase. This depends on patch 11, which makes the transition
manager skip style changes that it posts while starting transitions, to
ensure that this doesn't lead to an infinite loop. This also depends on
patch 16, which only consumes restyle data for the primary frame, to
ensure that the animation restyles posted are processed properly. It
also depends on patch 14, which makes us retain data on finished
transitions, to avoid triggering extra transitions on descendants when
both an ancestor and a descendant transition an inherited property, and
the descendant does so faster.
This fixes a known failure in layout/style/test/test_animations.html and
test_animations_omta.html (as visible in the patch). I believe this is
because this patch changes us to compute keyframe values for animations
on top of a style context *with* animation data rather than one without,
which means what we're computing them on top of changes each time. (The
purpose of patch 3 was to avoid this in the case where avoiding it
matters, i.e., implicit 0% and 100% keyframes.)
2015-02-17 01:15:05 +03:00
|
|
|
// Everything that causes our animation data to change triggers a
|
|
|
|
// style change, which in turn triggers a non-animation restyle.
|
|
|
|
// Likewise, when we initially construct frames, we're not in a
|
|
|
|
// style change, but also not in an animation restyle.
|
|
|
|
|
|
|
|
const nsStyleDisplay* disp = aStyleContext->StyleDisplay();
|
2015-04-21 04:22:10 +03:00
|
|
|
AnimationCollection* collection =
|
2015-12-04 02:34:17 +03:00
|
|
|
GetAnimationCollection(aElement,
|
|
|
|
aStyleContext->GetPseudoType(),
|
|
|
|
false /* aCreateIfNeeded */);
|
Bug 960465 patch 17 - Remove separate animation and non-animation phases of restyling. r=birtles
Note that this means that when we start transitions, we post restyles
that are processed during the current restyling operation, rather than
in a later phase. This depends on patch 11, which makes the transition
manager skip style changes that it posts while starting transitions, to
ensure that this doesn't lead to an infinite loop. This also depends on
patch 16, which only consumes restyle data for the primary frame, to
ensure that the animation restyles posted are processed properly. It
also depends on patch 14, which makes us retain data on finished
transitions, to avoid triggering extra transitions on descendants when
both an ancestor and a descendant transition an inherited property, and
the descendant does so faster.
This fixes a known failure in layout/style/test/test_animations.html and
test_animations_omta.html (as visible in the patch). I believe this is
because this patch changes us to compute keyframe values for animations
on top of a style context *with* animation data rather than one without,
which means what we're computing them on top of changes each time. (The
purpose of patch 3 was to avoid this in the case where avoiding it
matters, i.e., implicit 0% and 100% keyframes.)
2015-02-17 01:15:05 +03:00
|
|
|
if (!collection &&
|
|
|
|
disp->mAnimationNameCount == 1 &&
|
|
|
|
disp->mAnimations[0].GetName().IsEmpty()) {
|
|
|
|
return nullptr;
|
|
|
|
}
|
2011-04-12 10:18:44 +04:00
|
|
|
|
2015-08-31 10:21:49 +03:00
|
|
|
nsAutoAnimationMutationBatch mb(aElement->OwnerDoc());
|
2015-03-14 08:34:40 +03:00
|
|
|
|
Bug 960465 patch 17 - Remove separate animation and non-animation phases of restyling. r=birtles
Note that this means that when we start transitions, we post restyles
that are processed during the current restyling operation, rather than
in a later phase. This depends on patch 11, which makes the transition
manager skip style changes that it posts while starting transitions, to
ensure that this doesn't lead to an infinite loop. This also depends on
patch 16, which only consumes restyle data for the primary frame, to
ensure that the animation restyles posted are processed properly. It
also depends on patch 14, which makes us retain data on finished
transitions, to avoid triggering extra transitions on descendants when
both an ancestor and a descendant transition an inherited property, and
the descendant does so faster.
This fixes a known failure in layout/style/test/test_animations.html and
test_animations_omta.html (as visible in the patch). I believe this is
because this patch changes us to compute keyframe values for animations
on top of a style context *with* animation data rather than one without,
which means what we're computing them on top of changes each time. (The
purpose of patch 3 was to avoid this in the case where avoiding it
matters, i.e., implicit 0% and 100% keyframes.)
2015-02-17 01:15:05 +03:00
|
|
|
// build the animations list
|
2015-04-10 04:34:22 +03:00
|
|
|
dom::DocumentTimeline* timeline = aElement->OwnerDoc()->Timeline();
|
2015-04-21 04:22:10 +03:00
|
|
|
AnimationPtrArray newAnimations;
|
2015-03-16 03:28:49 +03:00
|
|
|
if (!aStyleContext->IsInDisplayNoneSubtree()) {
|
2015-04-21 04:22:10 +03:00
|
|
|
BuildAnimations(aStyleContext, aElement, timeline, newAnimations);
|
2015-03-16 03:28:49 +03:00
|
|
|
}
|
2011-04-12 10:18:44 +04:00
|
|
|
|
2015-04-21 04:22:10 +03:00
|
|
|
if (newAnimations.IsEmpty()) {
|
2014-06-27 03:57:13 +04:00
|
|
|
if (collection) {
|
2015-03-20 07:10:00 +03:00
|
|
|
// There might be transitions that run now that animations don't
|
|
|
|
// override them.
|
|
|
|
mPresContext->TransitionManager()->
|
|
|
|
UpdateCascadeResultsWithAnimationsToBeDestroyed(collection);
|
|
|
|
|
Bug 960465 patch 17 - Remove separate animation and non-animation phases of restyling. r=birtles
Note that this means that when we start transitions, we post restyles
that are processed during the current restyling operation, rather than
in a later phase. This depends on patch 11, which makes the transition
manager skip style changes that it posts while starting transitions, to
ensure that this doesn't lead to an infinite loop. This also depends on
patch 16, which only consumes restyle data for the primary frame, to
ensure that the animation restyles posted are processed properly. It
also depends on patch 14, which makes us retain data on finished
transitions, to avoid triggering extra transitions on descendants when
both an ancestor and a descendant transition an inherited property, and
the descendant does so faster.
This fixes a known failure in layout/style/test/test_animations.html and
test_animations_omta.html (as visible in the patch). I believe this is
because this patch changes us to compute keyframe values for animations
on top of a style context *with* animation data rather than one without,
which means what we're computing them on top of changes each time. (The
purpose of patch 3 was to avoid this in the case where avoiding it
matters, i.e., implicit 0% and 100% keyframes.)
2015-02-17 01:15:05 +03:00
|
|
|
collection->Destroy();
|
|
|
|
}
|
|
|
|
return nullptr;
|
|
|
|
}
|
2011-04-12 10:18:44 +04:00
|
|
|
|
Bug 960465 patch 17 - Remove separate animation and non-animation phases of restyling. r=birtles
Note that this means that when we start transitions, we post restyles
that are processed during the current restyling operation, rather than
in a later phase. This depends on patch 11, which makes the transition
manager skip style changes that it posts while starting transitions, to
ensure that this doesn't lead to an infinite loop. This also depends on
patch 16, which only consumes restyle data for the primary frame, to
ensure that the animation restyles posted are processed properly. It
also depends on patch 14, which makes us retain data on finished
transitions, to avoid triggering extra transitions on descendants when
both an ancestor and a descendant transition an inherited property, and
the descendant does so faster.
This fixes a known failure in layout/style/test/test_animations.html and
test_animations_omta.html (as visible in the patch). I believe this is
because this patch changes us to compute keyframe values for animations
on top of a style context *with* animation data rather than one without,
which means what we're computing them on top of changes each time. (The
purpose of patch 3 was to avoid this in the case where avoiding it
matters, i.e., implicit 0% and 100% keyframes.)
2015-02-17 01:15:05 +03:00
|
|
|
if (collection) {
|
|
|
|
collection->mStyleRule = nullptr;
|
|
|
|
collection->mStyleRuleRefreshTime = TimeStamp();
|
|
|
|
collection->UpdateAnimationGeneration(mPresContext);
|
|
|
|
|
|
|
|
// Copy over the start times and (if still paused) pause starts
|
|
|
|
// for each animation (matching on name only) that was also in the
|
|
|
|
// old list of animations.
|
|
|
|
// This means that we honor dynamic changes, which isn't what the
|
|
|
|
// spec says to do, but WebKit seems to honor at least some of
|
|
|
|
// them. See
|
|
|
|
// http://lists.w3.org/Archives/Public/www-style/2011Apr/0079.html
|
|
|
|
// In order to honor what the spec said, we'd copy more data over
|
|
|
|
// (or potentially optimize BuildAnimations to avoid rebuilding it
|
|
|
|
// in the first place).
|
2015-04-21 04:22:10 +03:00
|
|
|
if (!collection->mAnimations.IsEmpty()) {
|
Bug 960465 patch 17 - Remove separate animation and non-animation phases of restyling. r=birtles
Note that this means that when we start transitions, we post restyles
that are processed during the current restyling operation, rather than
in a later phase. This depends on patch 11, which makes the transition
manager skip style changes that it posts while starting transitions, to
ensure that this doesn't lead to an infinite loop. This also depends on
patch 16, which only consumes restyle data for the primary frame, to
ensure that the animation restyles posted are processed properly. It
also depends on patch 14, which makes us retain data on finished
transitions, to avoid triggering extra transitions on descendants when
both an ancestor and a descendant transition an inherited property, and
the descendant does so faster.
This fixes a known failure in layout/style/test/test_animations.html and
test_animations_omta.html (as visible in the patch). I believe this is
because this patch changes us to compute keyframe values for animations
on top of a style context *with* animation data rather than one without,
which means what we're computing them on top of changes each time. (The
purpose of patch 3 was to avoid this in the case where avoiding it
matters, i.e., implicit 0% and 100% keyframes.)
2015-02-17 01:15:05 +03:00
|
|
|
|
2015-04-21 04:22:10 +03:00
|
|
|
for (size_t newIdx = newAnimations.Length(); newIdx-- != 0;) {
|
|
|
|
Animation* newAnim = newAnimations[newIdx];
|
Bug 960465 patch 17 - Remove separate animation and non-animation phases of restyling. r=birtles
Note that this means that when we start transitions, we post restyles
that are processed during the current restyling operation, rather than
in a later phase. This depends on patch 11, which makes the transition
manager skip style changes that it posts while starting transitions, to
ensure that this doesn't lead to an infinite loop. This also depends on
patch 16, which only consumes restyle data for the primary frame, to
ensure that the animation restyles posted are processed properly. It
also depends on patch 14, which makes us retain data on finished
transitions, to avoid triggering extra transitions on descendants when
both an ancestor and a descendant transition an inherited property, and
the descendant does so faster.
This fixes a known failure in layout/style/test/test_animations.html and
test_animations_omta.html (as visible in the patch). I believe this is
because this patch changes us to compute keyframe values for animations
on top of a style context *with* animation data rather than one without,
which means what we're computing them on top of changes each time. (The
purpose of patch 3 was to avoid this in the case where avoiding it
matters, i.e., implicit 0% and 100% keyframes.)
2015-02-17 01:15:05 +03:00
|
|
|
|
|
|
|
// Find the matching animation with this name in the old list
|
|
|
|
// of animations. We iterate through both lists in a backwards
|
|
|
|
// direction which means that if there are more animations in
|
|
|
|
// the new list of animations with a given name than in the old
|
|
|
|
// list, it will be the animations towards the of the beginning of
|
|
|
|
// the list that do not match and are treated as new animations.
|
2015-10-18 08:24:48 +03:00
|
|
|
RefPtr<CSSAnimation> oldAnim;
|
2015-04-21 04:22:10 +03:00
|
|
|
size_t oldIdx = collection->mAnimations.Length();
|
Bug 960465 patch 17 - Remove separate animation and non-animation phases of restyling. r=birtles
Note that this means that when we start transitions, we post restyles
that are processed during the current restyling operation, rather than
in a later phase. This depends on patch 11, which makes the transition
manager skip style changes that it posts while starting transitions, to
ensure that this doesn't lead to an infinite loop. This also depends on
patch 16, which only consumes restyle data for the primary frame, to
ensure that the animation restyles posted are processed properly. It
also depends on patch 14, which makes us retain data on finished
transitions, to avoid triggering extra transitions on descendants when
both an ancestor and a descendant transition an inherited property, and
the descendant does so faster.
This fixes a known failure in layout/style/test/test_animations.html and
test_animations_omta.html (as visible in the patch). I believe this is
because this patch changes us to compute keyframe values for animations
on top of a style context *with* animation data rather than one without,
which means what we're computing them on top of changes each time. (The
purpose of patch 3 was to avoid this in the case where avoiding it
matters, i.e., implicit 0% and 100% keyframes.)
2015-02-17 01:15:05 +03:00
|
|
|
while (oldIdx-- != 0) {
|
2015-04-21 04:22:10 +03:00
|
|
|
CSSAnimation* a = collection->mAnimations[oldIdx]->AsCSSAnimation();
|
|
|
|
MOZ_ASSERT(a, "All animations in the CSS Animation collection should"
|
|
|
|
" be CSSAnimation objects");
|
2015-07-01 09:19:04 +03:00
|
|
|
if (a->AnimationName() ==
|
|
|
|
newAnim->AsCSSAnimation()->AnimationName()) {
|
2015-04-21 04:22:10 +03:00
|
|
|
oldAnim = a;
|
Bug 960465 patch 17 - Remove separate animation and non-animation phases of restyling. r=birtles
Note that this means that when we start transitions, we post restyles
that are processed during the current restyling operation, rather than
in a later phase. This depends on patch 11, which makes the transition
manager skip style changes that it posts while starting transitions, to
ensure that this doesn't lead to an infinite loop. This also depends on
patch 16, which only consumes restyle data for the primary frame, to
ensure that the animation restyles posted are processed properly. It
also depends on patch 14, which makes us retain data on finished
transitions, to avoid triggering extra transitions on descendants when
both an ancestor and a descendant transition an inherited property, and
the descendant does so faster.
This fixes a known failure in layout/style/test/test_animations.html and
test_animations_omta.html (as visible in the patch). I believe this is
because this patch changes us to compute keyframe values for animations
on top of a style context *with* animation data rather than one without,
which means what we're computing them on top of changes each time. (The
purpose of patch 3 was to avoid this in the case where avoiding it
matters, i.e., implicit 0% and 100% keyframes.)
2015-02-17 01:15:05 +03:00
|
|
|
break;
|
2014-08-10 11:06:49 +04:00
|
|
|
}
|
Bug 960465 patch 17 - Remove separate animation and non-animation phases of restyling. r=birtles
Note that this means that when we start transitions, we post restyles
that are processed during the current restyling operation, rather than
in a later phase. This depends on patch 11, which makes the transition
manager skip style changes that it posts while starting transitions, to
ensure that this doesn't lead to an infinite loop. This also depends on
patch 16, which only consumes restyle data for the primary frame, to
ensure that the animation restyles posted are processed properly. It
also depends on patch 14, which makes us retain data on finished
transitions, to avoid triggering extra transitions on descendants when
both an ancestor and a descendant transition an inherited property, and
the descendant does so faster.
This fixes a known failure in layout/style/test/test_animations.html and
test_animations_omta.html (as visible in the patch). I believe this is
because this patch changes us to compute keyframe values for animations
on top of a style context *with* animation data rather than one without,
which means what we're computing them on top of changes each time. (The
purpose of patch 3 was to avoid this in the case where avoiding it
matters, i.e., implicit 0% and 100% keyframes.)
2015-02-17 01:15:05 +03:00
|
|
|
}
|
2015-04-21 04:22:10 +03:00
|
|
|
if (!oldAnim) {
|
2015-08-17 07:59:45 +03:00
|
|
|
// FIXME: Bug 1134163 - We shouldn't queue animationstart events
|
|
|
|
// until the animation is actually ready to run. However, we
|
|
|
|
// currently have some tests that assume that these events are
|
|
|
|
// dispatched within the same tick as the animation is added
|
|
|
|
// so we need to queue up any animationstart events from newly-created
|
|
|
|
// animations.
|
|
|
|
newAnim->AsCSSAnimation()->QueueEvents();
|
Bug 960465 patch 17 - Remove separate animation and non-animation phases of restyling. r=birtles
Note that this means that when we start transitions, we post restyles
that are processed during the current restyling operation, rather than
in a later phase. This depends on patch 11, which makes the transition
manager skip style changes that it posts while starting transitions, to
ensure that this doesn't lead to an infinite loop. This also depends on
patch 16, which only consumes restyle data for the primary frame, to
ensure that the animation restyles posted are processed properly. It
also depends on patch 14, which makes us retain data on finished
transitions, to avoid triggering extra transitions on descendants when
both an ancestor and a descendant transition an inherited property, and
the descendant does so faster.
This fixes a known failure in layout/style/test/test_animations.html and
test_animations_omta.html (as visible in the patch). I believe this is
because this patch changes us to compute keyframe values for animations
on top of a style context *with* animation data rather than one without,
which means what we're computing them on top of changes each time. (The
purpose of patch 3 was to avoid this in the case where avoiding it
matters, i.e., implicit 0% and 100% keyframes.)
2015-02-17 01:15:05 +03:00
|
|
|
continue;
|
|
|
|
}
|
2014-07-23 05:51:12 +04:00
|
|
|
|
2015-03-14 08:34:40 +03:00
|
|
|
bool animationChanged = false;
|
|
|
|
|
Bug 960465 patch 17 - Remove separate animation and non-animation phases of restyling. r=birtles
Note that this means that when we start transitions, we post restyles
that are processed during the current restyling operation, rather than
in a later phase. This depends on patch 11, which makes the transition
manager skip style changes that it posts while starting transitions, to
ensure that this doesn't lead to an infinite loop. This also depends on
patch 16, which only consumes restyle data for the primary frame, to
ensure that the animation restyles posted are processed properly. It
also depends on patch 14, which makes us retain data on finished
transitions, to avoid triggering extra transitions on descendants when
both an ancestor and a descendant transition an inherited property, and
the descendant does so faster.
This fixes a known failure in layout/style/test/test_animations.html and
test_animations_omta.html (as visible in the patch). I believe this is
because this patch changes us to compute keyframe values for animations
on top of a style context *with* animation data rather than one without,
which means what we're computing them on top of changes each time. (The
purpose of patch 3 was to avoid this in the case where avoiding it
matters, i.e., implicit 0% and 100% keyframes.)
2015-02-17 01:15:05 +03:00
|
|
|
// Update the old from the new so we can keep the original object
|
|
|
|
// identity (and any expando properties attached to it).
|
2015-04-21 04:22:10 +03:00
|
|
|
if (oldAnim->GetEffect() && newAnim->GetEffect()) {
|
2015-04-30 16:06:43 +03:00
|
|
|
KeyframeEffectReadOnly* oldEffect = oldAnim->GetEffect();
|
|
|
|
KeyframeEffectReadOnly* newEffect = newAnim->GetEffect();
|
2015-03-14 08:34:40 +03:00
|
|
|
animationChanged =
|
2015-04-15 02:48:21 +03:00
|
|
|
oldEffect->Timing() != newEffect->Timing() ||
|
|
|
|
oldEffect->Properties() != newEffect->Properties();
|
2015-10-07 08:30:27 +03:00
|
|
|
oldEffect->SetTiming(newEffect->Timing());
|
2015-12-20 16:17:00 +03:00
|
|
|
|
|
|
|
// To preserve the mIsRunningOnCompositor value on each property,
|
|
|
|
// we copy it from the old effect to the new effect since, in the
|
|
|
|
// following step, we will completely clobber the properties on the
|
|
|
|
// old effect with the values on the new effect.
|
|
|
|
CopyIsRunningOnCompositor(*oldEffect, *newEffect);
|
2015-04-15 02:48:21 +03:00
|
|
|
oldEffect->Properties() = newEffect->Properties();
|
Bug 960465 patch 17 - Remove separate animation and non-animation phases of restyling. r=birtles
Note that this means that when we start transitions, we post restyles
that are processed during the current restyling operation, rather than
in a later phase. This depends on patch 11, which makes the transition
manager skip style changes that it posts while starting transitions, to
ensure that this doesn't lead to an infinite loop. This also depends on
patch 16, which only consumes restyle data for the primary frame, to
ensure that the animation restyles posted are processed properly. It
also depends on patch 14, which makes us retain data on finished
transitions, to avoid triggering extra transitions on descendants when
both an ancestor and a descendant transition an inherited property, and
the descendant does so faster.
This fixes a known failure in layout/style/test/test_animations.html and
test_animations_omta.html (as visible in the patch). I believe this is
because this patch changes us to compute keyframe values for animations
on top of a style context *with* animation data rather than one without,
which means what we're computing them on top of changes each time. (The
purpose of patch 3 was to avoid this in the case where avoiding it
matters, i.e., implicit 0% and 100% keyframes.)
2015-02-17 01:15:05 +03:00
|
|
|
}
|
2014-07-23 05:51:12 +04:00
|
|
|
|
2015-04-27 02:53:19 +03:00
|
|
|
// Handle changes in play state. If the animation is idle, however,
|
|
|
|
// changes to animation-play-state should *not* restart it.
|
|
|
|
if (oldAnim->PlayState() != AnimationPlayState::Idle) {
|
|
|
|
// CSSAnimation takes care of override behavior so that,
|
|
|
|
// for example, if the author has called pause(), that will
|
|
|
|
// override the animation-play-state.
|
|
|
|
// (We should check newAnim->IsStylePaused() but that requires
|
|
|
|
// downcasting to CSSAnimation and we happen to know that
|
|
|
|
// newAnim will only ever be paused by calling PauseFromStyle
|
|
|
|
// making IsPausedOrPausing synonymous in this case.)
|
|
|
|
if (!oldAnim->IsStylePaused() && newAnim->IsPausedOrPausing()) {
|
|
|
|
oldAnim->PauseFromStyle();
|
|
|
|
animationChanged = true;
|
|
|
|
} else if (oldAnim->IsStylePaused() &&
|
|
|
|
!newAnim->IsPausedOrPausing()) {
|
|
|
|
oldAnim->PlayFromStyle();
|
|
|
|
animationChanged = true;
|
|
|
|
}
|
2015-03-14 08:34:40 +03:00
|
|
|
}
|
|
|
|
|
2015-06-09 05:13:54 +03:00
|
|
|
oldAnim->CopyAnimationIndex(*newAnim->AsCSSAnimation());
|
|
|
|
|
2015-08-17 07:59:45 +03:00
|
|
|
// Updating the effect timing above might already have caused the
|
|
|
|
// animation to become irrelevant so only add a changed record if
|
|
|
|
// the animation is still relevant.
|
|
|
|
if (animationChanged && oldAnim->IsRelevant()) {
|
2015-04-21 04:22:10 +03:00
|
|
|
nsNodeUtils::AnimationChanged(oldAnim);
|
2011-04-12 10:18:44 +04:00
|
|
|
}
|
Bug 960465 patch 17 - Remove separate animation and non-animation phases of restyling. r=birtles
Note that this means that when we start transitions, we post restyles
that are processed during the current restyling operation, rather than
in a later phase. This depends on patch 11, which makes the transition
manager skip style changes that it posts while starting transitions, to
ensure that this doesn't lead to an infinite loop. This also depends on
patch 16, which only consumes restyle data for the primary frame, to
ensure that the animation restyles posted are processed properly. It
also depends on patch 14, which makes us retain data on finished
transitions, to avoid triggering extra transitions on descendants when
both an ancestor and a descendant transition an inherited property, and
the descendant does so faster.
This fixes a known failure in layout/style/test/test_animations.html and
test_animations_omta.html (as visible in the patch). I believe this is
because this patch changes us to compute keyframe values for animations
on top of a style context *with* animation data rather than one without,
which means what we're computing them on top of changes each time. (The
purpose of patch 3 was to avoid this in the case where avoiding it
matters, i.e., implicit 0% and 100% keyframes.)
2015-02-17 01:15:05 +03:00
|
|
|
|
|
|
|
// Replace new animation with the (updated) old one and remove the
|
|
|
|
// old one from the array so we don't try to match it any more.
|
|
|
|
//
|
|
|
|
// Although we're doing this while iterating this is safe because
|
2015-04-21 04:22:10 +03:00
|
|
|
// we're not changing the length of newAnimations and we've finished
|
Bug 960465 patch 17 - Remove separate animation and non-animation phases of restyling. r=birtles
Note that this means that when we start transitions, we post restyles
that are processed during the current restyling operation, rather than
in a later phase. This depends on patch 11, which makes the transition
manager skip style changes that it posts while starting transitions, to
ensure that this doesn't lead to an infinite loop. This also depends on
patch 16, which only consumes restyle data for the primary frame, to
ensure that the animation restyles posted are processed properly. It
also depends on patch 14, which makes us retain data on finished
transitions, to avoid triggering extra transitions on descendants when
both an ancestor and a descendant transition an inherited property, and
the descendant does so faster.
This fixes a known failure in layout/style/test/test_animations.html and
test_animations_omta.html (as visible in the patch). I believe this is
because this patch changes us to compute keyframe values for animations
on top of a style context *with* animation data rather than one without,
which means what we're computing them on top of changes each time. (The
purpose of patch 3 was to avoid this in the case where avoiding it
matters, i.e., implicit 0% and 100% keyframes.)
2015-02-17 01:15:05 +03:00
|
|
|
// iterating over the list of old iterations.
|
2015-04-27 02:53:19 +03:00
|
|
|
newAnim->CancelFromStyle();
|
2015-04-21 04:22:10 +03:00
|
|
|
newAnim = nullptr;
|
|
|
|
newAnimations.ReplaceElementAt(newIdx, oldAnim);
|
|
|
|
collection->mAnimations.RemoveElementAt(oldIdx);
|
2011-04-12 10:18:44 +04:00
|
|
|
}
|
|
|
|
}
|
Bug 960465 patch 17 - Remove separate animation and non-animation phases of restyling. r=birtles
Note that this means that when we start transitions, we post restyles
that are processed during the current restyling operation, rather than
in a later phase. This depends on patch 11, which makes the transition
manager skip style changes that it posts while starting transitions, to
ensure that this doesn't lead to an infinite loop. This also depends on
patch 16, which only consumes restyle data for the primary frame, to
ensure that the animation restyles posted are processed properly. It
also depends on patch 14, which makes us retain data on finished
transitions, to avoid triggering extra transitions on descendants when
both an ancestor and a descendant transition an inherited property, and
the descendant does so faster.
This fixes a known failure in layout/style/test/test_animations.html and
test_animations_omta.html (as visible in the patch). I believe this is
because this patch changes us to compute keyframe values for animations
on top of a style context *with* animation data rather than one without,
which means what we're computing them on top of changes each time. (The
purpose of patch 3 was to avoid this in the case where avoiding it
matters, i.e., implicit 0% and 100% keyframes.)
2015-02-17 01:15:05 +03:00
|
|
|
} else {
|
2015-12-04 02:34:17 +03:00
|
|
|
collection = GetAnimationCollection(aElement,
|
|
|
|
aStyleContext->GetPseudoType(),
|
|
|
|
true /* aCreateIfNeeded */);
|
2015-08-17 07:59:45 +03:00
|
|
|
for (Animation* animation : newAnimations) {
|
|
|
|
// FIXME: Bug 1134163 - As above, we have shouldn't actually need to
|
|
|
|
// queue events here. (But we do for now since some tests expect
|
|
|
|
// animationstart events to be dispatched immediately.)
|
|
|
|
animation->AsCSSAnimation()->QueueEvents();
|
|
|
|
}
|
Bug 960465 patch 17 - Remove separate animation and non-animation phases of restyling. r=birtles
Note that this means that when we start transitions, we post restyles
that are processed during the current restyling operation, rather than
in a later phase. This depends on patch 11, which makes the transition
manager skip style changes that it posts while starting transitions, to
ensure that this doesn't lead to an infinite loop. This also depends on
patch 16, which only consumes restyle data for the primary frame, to
ensure that the animation restyles posted are processed properly. It
also depends on patch 14, which makes us retain data on finished
transitions, to avoid triggering extra transitions on descendants when
both an ancestor and a descendant transition an inherited property, and
the descendant does so faster.
This fixes a known failure in layout/style/test/test_animations.html and
test_animations_omta.html (as visible in the patch). I believe this is
because this patch changes us to compute keyframe values for animations
on top of a style context *with* animation data rather than one without,
which means what we're computing them on top of changes each time. (The
purpose of patch 3 was to avoid this in the case where avoiding it
matters, i.e., implicit 0% and 100% keyframes.)
2015-02-17 01:15:05 +03:00
|
|
|
}
|
2015-04-21 04:22:10 +03:00
|
|
|
collection->mAnimations.SwapElements(newAnimations);
|
2015-09-17 09:43:15 +03:00
|
|
|
collection->mStyleChanging = true;
|
2011-04-12 10:18:44 +04:00
|
|
|
|
Bug 960465 patch 17 - Remove separate animation and non-animation phases of restyling. r=birtles
Note that this means that when we start transitions, we post restyles
that are processed during the current restyling operation, rather than
in a later phase. This depends on patch 11, which makes the transition
manager skip style changes that it posts while starting transitions, to
ensure that this doesn't lead to an infinite loop. This also depends on
patch 16, which only consumes restyle data for the primary frame, to
ensure that the animation restyles posted are processed properly. It
also depends on patch 14, which makes us retain data on finished
transitions, to avoid triggering extra transitions on descendants when
both an ancestor and a descendant transition an inherited property, and
the descendant does so faster.
This fixes a known failure in layout/style/test/test_animations.html and
test_animations_omta.html (as visible in the patch). I believe this is
because this patch changes us to compute keyframe values for animations
on top of a style context *with* animation data rather than one without,
which means what we're computing them on top of changes each time. (The
purpose of patch 3 was to avoid this in the case where avoiding it
matters, i.e., implicit 0% and 100% keyframes.)
2015-02-17 01:15:05 +03:00
|
|
|
// Cancel removed animations
|
2015-04-21 04:22:10 +03:00
|
|
|
for (size_t newAnimIdx = newAnimations.Length(); newAnimIdx-- != 0; ) {
|
2015-04-27 02:53:19 +03:00
|
|
|
newAnimations[newAnimIdx]->CancelFromStyle();
|
Bug 960465 patch 17 - Remove separate animation and non-animation phases of restyling. r=birtles
Note that this means that when we start transitions, we post restyles
that are processed during the current restyling operation, rather than
in a later phase. This depends on patch 11, which makes the transition
manager skip style changes that it posts while starting transitions, to
ensure that this doesn't lead to an infinite loop. This also depends on
patch 16, which only consumes restyle data for the primary frame, to
ensure that the animation restyles posted are processed properly. It
also depends on patch 14, which makes us retain data on finished
transitions, to avoid triggering extra transitions on descendants when
both an ancestor and a descendant transition an inherited property, and
the descendant does so faster.
This fixes a known failure in layout/style/test/test_animations.html and
test_animations_omta.html (as visible in the patch). I believe this is
because this patch changes us to compute keyframe values for animations
on top of a style context *with* animation data rather than one without,
which means what we're computing them on top of changes each time. (The
purpose of patch 3 was to avoid this in the case where avoiding it
matters, i.e., implicit 0% and 100% keyframes.)
2015-02-17 01:15:05 +03:00
|
|
|
}
|
2014-12-18 02:42:41 +03:00
|
|
|
|
2015-04-01 01:05:54 +03:00
|
|
|
UpdateCascadeResults(aStyleContext, collection);
|
|
|
|
|
Bug 960465 patch 17 - Remove separate animation and non-animation phases of restyling. r=birtles
Note that this means that when we start transitions, we post restyles
that are processed during the current restyling operation, rather than
in a later phase. This depends on patch 11, which makes the transition
manager skip style changes that it posts while starting transitions, to
ensure that this doesn't lead to an infinite loop. This also depends on
patch 16, which only consumes restyle data for the primary frame, to
ensure that the animation restyles posted are processed properly. It
also depends on patch 14, which makes us retain data on finished
transitions, to avoid triggering extra transitions on descendants when
both an ancestor and a descendant transition an inherited property, and
the descendant does so faster.
This fixes a known failure in layout/style/test/test_animations.html and
test_animations_omta.html (as visible in the patch). I believe this is
because this patch changes us to compute keyframe values for animations
on top of a style context *with* animation data rather than one without,
which means what we're computing them on top of changes each time. (The
purpose of patch 3 was to avoid this in the case where avoiding it
matters, i.e., implicit 0% and 100% keyframes.)
2015-02-17 01:15:05 +03:00
|
|
|
TimeStamp refreshTime = mPresContext->RefreshDriver()->MostRecentRefresh();
|
2015-08-18 10:11:55 +03:00
|
|
|
collection->EnsureStyleRuleFor(refreshTime);
|
2015-07-29 04:57:39 +03:00
|
|
|
// We don't actually dispatch the pending events now. We'll either
|
Bug 960465 patch 17 - Remove separate animation and non-animation phases of restyling. r=birtles
Note that this means that when we start transitions, we post restyles
that are processed during the current restyling operation, rather than
in a later phase. This depends on patch 11, which makes the transition
manager skip style changes that it posts while starting transitions, to
ensure that this doesn't lead to an infinite loop. This also depends on
patch 16, which only consumes restyle data for the primary frame, to
ensure that the animation restyles posted are processed properly. It
also depends on patch 14, which makes us retain data on finished
transitions, to avoid triggering extra transitions on descendants when
both an ancestor and a descendant transition an inherited property, and
the descendant does so faster.
This fixes a known failure in layout/style/test/test_animations.html and
test_animations_omta.html (as visible in the patch). I believe this is
because this patch changes us to compute keyframe values for animations
on top of a style context *with* animation data rather than one without,
which means what we're computing them on top of changes each time. (The
purpose of patch 3 was to avoid this in the case where avoiding it
matters, i.e., implicit 0% and 100% keyframes.)
2015-02-17 01:15:05 +03:00
|
|
|
// dispatch them the next time we get a refresh driver notification
|
|
|
|
// or the next time somebody calls
|
|
|
|
// nsPresShell::FlushPendingNotifications.
|
2015-07-29 04:57:39 +03:00
|
|
|
if (mEventDispatcher.HasQueuedEvents()) {
|
Bug 960465 patch 17 - Remove separate animation and non-animation phases of restyling. r=birtles
Note that this means that when we start transitions, we post restyles
that are processed during the current restyling operation, rather than
in a later phase. This depends on patch 11, which makes the transition
manager skip style changes that it posts while starting transitions, to
ensure that this doesn't lead to an infinite loop. This also depends on
patch 16, which only consumes restyle data for the primary frame, to
ensure that the animation restyles posted are processed properly. It
also depends on patch 14, which makes us retain data on finished
transitions, to avoid triggering extra transitions on descendants when
both an ancestor and a descendant transition an inherited property, and
the descendant does so faster.
This fixes a known failure in layout/style/test/test_animations.html and
test_animations_omta.html (as visible in the patch). I believe this is
because this patch changes us to compute keyframe values for animations
on top of a style context *with* animation data rather than one without,
which means what we're computing them on top of changes each time. (The
purpose of patch 3 was to avoid this in the case where avoiding it
matters, i.e., implicit 0% and 100% keyframes.)
2015-02-17 01:15:05 +03:00
|
|
|
mPresContext->Document()->SetNeedStyleFlush();
|
2011-04-12 10:18:44 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
return GetAnimationRule(aElement, aStyleContext->GetPseudoType());
|
|
|
|
}
|
|
|
|
|
2015-09-15 00:42:00 +03:00
|
|
|
void
|
|
|
|
nsAnimationManager::StopAnimationsForElement(
|
|
|
|
mozilla::dom::Element* aElement,
|
|
|
|
nsCSSPseudoElements::Type aPseudoType)
|
|
|
|
{
|
|
|
|
MOZ_ASSERT(aElement);
|
|
|
|
AnimationCollection* collection =
|
2015-12-04 02:34:17 +03:00
|
|
|
GetAnimationCollection(aElement, aPseudoType, false /* aCreateIfNeeded */);
|
2015-09-15 00:42:00 +03:00
|
|
|
if (!collection) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
nsAutoAnimationMutationBatch mb(aElement->OwnerDoc());
|
|
|
|
collection->Destroy();
|
|
|
|
}
|
|
|
|
|
2011-04-12 10:18:44 +04:00
|
|
|
struct KeyframeData {
|
|
|
|
float mKey;
|
2012-08-22 19:56:38 +04:00
|
|
|
uint32_t mIndex; // store original order since sort algorithm is not stable
|
2011-04-12 10:18:44 +04:00
|
|
|
nsCSSKeyframeRule *mRule;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct KeyframeDataComparator {
|
2011-09-29 10:19:26 +04:00
|
|
|
bool Equals(const KeyframeData& A, const KeyframeData& B) const {
|
2012-03-22 09:10:02 +04:00
|
|
|
return A.mKey == B.mKey && A.mIndex == B.mIndex;
|
2011-04-12 10:18:44 +04:00
|
|
|
}
|
2011-09-29 10:19:26 +04:00
|
|
|
bool LessThan(const KeyframeData& A, const KeyframeData& B) const {
|
2012-03-22 09:10:02 +04:00
|
|
|
return A.mKey < B.mKey || (A.mKey == B.mKey && A.mIndex < B.mIndex);
|
2011-04-12 10:18:44 +04:00
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
class ResolvedStyleCache {
|
|
|
|
public:
|
2014-08-06 17:31:21 +04:00
|
|
|
ResolvedStyleCache() : mCache() {}
|
2011-04-12 10:18:44 +04:00
|
|
|
nsStyleContext* Get(nsPresContext *aPresContext,
|
|
|
|
nsStyleContext *aParentStyleContext,
|
2015-11-05 11:44:11 +03:00
|
|
|
Declaration* aKeyframeDeclaration);
|
2011-04-12 10:18:44 +04:00
|
|
|
|
|
|
|
private:
|
2015-11-05 11:44:11 +03:00
|
|
|
nsRefPtrHashtable<nsPtrHashKey<Declaration>, nsStyleContext> mCache;
|
2011-04-12 10:18:44 +04:00
|
|
|
};
|
|
|
|
|
|
|
|
nsStyleContext*
|
|
|
|
ResolvedStyleCache::Get(nsPresContext *aPresContext,
|
|
|
|
nsStyleContext *aParentStyleContext,
|
2015-11-05 11:44:11 +03:00
|
|
|
Declaration* aKeyframeDeclaration)
|
2011-04-12 10:18:44 +04:00
|
|
|
{
|
|
|
|
// FIXME (spec): The css3-animations spec isn't very clear about how
|
|
|
|
// properties are resolved when they have values that depend on other
|
|
|
|
// properties (e.g., values in 'em'). I presume that they're resolved
|
|
|
|
// relative to the other styles of the element. The question is
|
|
|
|
// whether they are resolved relative to other animations: I assume
|
|
|
|
// that they're not, since that would prevent us from caching a lot of
|
|
|
|
// data that we'd really like to cache (in particular, the
|
2014-06-24 10:29:54 +04:00
|
|
|
// StyleAnimationValue values in AnimationPropertySegment).
|
2015-11-05 11:44:11 +03:00
|
|
|
nsStyleContext *result = mCache.GetWeak(aKeyframeDeclaration);
|
2011-04-12 10:18:44 +04:00
|
|
|
if (!result) {
|
2015-11-05 11:44:11 +03:00
|
|
|
aKeyframeDeclaration->SetImmutable();
|
2015-11-05 11:44:09 +03:00
|
|
|
// The spec says that !important declarations should just be ignored
|
2015-11-05 11:44:11 +03:00
|
|
|
MOZ_ASSERT(!aKeyframeDeclaration->HasImportantData(),
|
2015-11-05 11:44:09 +03:00
|
|
|
"Keyframe rule has !important data");
|
|
|
|
|
2011-04-12 10:18:44 +04:00
|
|
|
nsCOMArray<nsIStyleRule> rules;
|
2015-11-05 11:44:11 +03:00
|
|
|
rules.AppendObject(aKeyframeDeclaration);
|
2015-10-18 08:24:48 +03:00
|
|
|
RefPtr<nsStyleContext> resultStrong = aPresContext->StyleSet()->
|
2011-04-12 10:18:44 +04:00
|
|
|
ResolveStyleByAddingRules(aParentStyleContext, rules);
|
2015-11-05 11:44:11 +03:00
|
|
|
mCache.Put(aKeyframeDeclaration, resultStrong);
|
2011-04-12 10:18:44 +04:00
|
|
|
result = resultStrong;
|
|
|
|
}
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
nsAnimationManager::BuildAnimations(nsStyleContext* aStyleContext,
|
2014-10-02 10:14:15 +04:00
|
|
|
dom::Element* aTarget,
|
2015-04-28 05:29:13 +03:00
|
|
|
dom::AnimationTimeline* aTimeline,
|
2015-04-21 04:22:10 +03:00
|
|
|
AnimationPtrArray& aAnimations)
|
2011-04-12 10:18:44 +04:00
|
|
|
{
|
2015-04-21 04:22:10 +03:00
|
|
|
MOZ_ASSERT(aAnimations.IsEmpty(), "expect empty array");
|
2011-04-12 10:18:44 +04:00
|
|
|
|
|
|
|
ResolvedStyleCache resolvedStyles;
|
|
|
|
|
2013-02-17 01:51:02 +04:00
|
|
|
const nsStyleDisplay *disp = aStyleContext->StyleDisplay();
|
2014-07-16 04:02:32 +04:00
|
|
|
|
2015-10-18 08:24:48 +03:00
|
|
|
RefPtr<nsStyleContext> styleWithoutAnimation;
|
2015-02-17 01:15:01 +03:00
|
|
|
|
2014-08-10 11:06:48 +04:00
|
|
|
for (size_t animIdx = 0, animEnd = disp->mAnimationNameCount;
|
2011-04-23 05:36:23 +04:00
|
|
|
animIdx != animEnd; ++animIdx) {
|
2014-06-27 03:57:11 +04:00
|
|
|
const StyleAnimation& src = disp->mAnimations[animIdx];
|
2014-07-03 04:04:16 +04:00
|
|
|
|
2014-07-09 04:13:33 +04:00
|
|
|
// CSS Animations whose animation-name does not match a @keyframes rule do
|
|
|
|
// not generate animation events. This includes when the animation-name is
|
|
|
|
// "none" which is represented by an empty name in the StyleAnimation.
|
|
|
|
// Since such animations neither affect style nor dispatch events, we do
|
2015-04-21 04:22:09 +03:00
|
|
|
// not generate a corresponding Animation for them.
|
2014-07-09 04:13:33 +04:00
|
|
|
nsCSSKeyframesRule* rule =
|
|
|
|
src.GetName().IsEmpty()
|
|
|
|
? nullptr
|
2015-04-17 04:09:59 +03:00
|
|
|
: mPresContext->StyleSet()->KeyframesRuleForName(src.GetName());
|
2014-07-09 04:13:33 +04:00
|
|
|
if (!rule) {
|
2014-07-03 04:04:16 +04:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2015-10-18 08:24:48 +03:00
|
|
|
RefPtr<CSSAnimation> dest =
|
2015-04-28 11:21:58 +03:00
|
|
|
new CSSAnimation(mPresContext->Document()->GetScopeObject(),
|
2015-04-28 09:48:35 +03:00
|
|
|
src.GetName());
|
2015-06-09 05:13:54 +03:00
|
|
|
dest->SetOwningElement(
|
|
|
|
OwningElementRef(*aTarget, aStyleContext->GetPseudoType()));
|
2015-04-28 11:21:58 +03:00
|
|
|
dest->SetTimeline(aTimeline);
|
2015-06-09 05:13:54 +03:00
|
|
|
dest->SetAnimationIndex(static_cast<uint64_t>(animIdx));
|
2015-04-21 04:22:10 +03:00
|
|
|
aAnimations.AppendElement(dest);
|
2014-05-15 03:38:37 +04:00
|
|
|
|
2014-08-10 11:06:50 +04:00
|
|
|
AnimationTiming timing;
|
|
|
|
timing.mIterationDuration =
|
2014-05-28 11:51:49 +04:00
|
|
|
TimeDuration::FromMilliseconds(src.GetDuration());
|
2014-08-10 11:06:50 +04:00
|
|
|
timing.mDelay = TimeDuration::FromMilliseconds(src.GetDelay());
|
|
|
|
timing.mIterationCount = src.GetIterationCount();
|
|
|
|
timing.mDirection = src.GetDirection();
|
|
|
|
timing.mFillMode = src.GetFillMode();
|
2014-05-15 03:38:37 +04:00
|
|
|
|
2015-10-18 08:24:48 +03:00
|
|
|
RefPtr<KeyframeEffectReadOnly> destEffect =
|
2015-04-30 16:06:43 +03:00
|
|
|
new KeyframeEffectReadOnly(mPresContext->Document(), aTarget,
|
2015-07-01 09:19:04 +03:00
|
|
|
aStyleContext->GetPseudoType(), timing);
|
2015-04-15 02:48:21 +03:00
|
|
|
dest->SetEffect(destEffect);
|
2014-08-10 11:06:47 +04:00
|
|
|
|
2014-10-20 08:55:44 +04:00
|
|
|
if (src.GetPlayState() == NS_STYLE_ANIMATION_PLAY_STATE_PAUSED) {
|
|
|
|
dest->PauseFromStyle();
|
2015-05-19 09:07:59 +03:00
|
|
|
} else {
|
|
|
|
dest->PlayFromStyle();
|
2011-04-12 10:18:44 +04:00
|
|
|
}
|
|
|
|
|
2012-03-22 09:10:02 +04:00
|
|
|
// While current drafts of css3-animations say that later keyframes
|
|
|
|
// with the same key entirely replace earlier ones (no cascading),
|
|
|
|
// this is a bad idea and contradictory to the rest of CSS. So
|
|
|
|
// we're going to keep all the keyframes for each key and then do
|
|
|
|
// the replacement on a per-property basis rather than a per-rule
|
|
|
|
// basis, just like everything else in CSS.
|
|
|
|
|
|
|
|
AutoInfallibleTArray<KeyframeData, 16> sortedKeyframes;
|
|
|
|
|
2012-08-22 19:56:38 +04:00
|
|
|
for (uint32_t ruleIdx = 0, ruleEnd = rule->StyleRuleCount();
|
2011-04-23 05:36:23 +04:00
|
|
|
ruleIdx != ruleEnd; ++ruleIdx) {
|
2011-04-08 05:23:46 +04:00
|
|
|
css::Rule* cssRule = rule->GetStyleRuleAt(ruleIdx);
|
2015-02-10 01:34:50 +03:00
|
|
|
MOZ_ASSERT(cssRule, "must have rule");
|
|
|
|
MOZ_ASSERT(cssRule->GetType() == css::Rule::KEYFRAME_RULE,
|
|
|
|
"must be keyframe rule");
|
2011-04-12 10:18:44 +04:00
|
|
|
nsCSSKeyframeRule *kfRule = static_cast<nsCSSKeyframeRule*>(cssRule);
|
|
|
|
|
|
|
|
const nsTArray<float> &keys = kfRule->GetKeys();
|
2012-08-22 19:56:38 +04:00
|
|
|
for (uint32_t keyIdx = 0, keyEnd = keys.Length();
|
2011-04-23 05:36:23 +04:00
|
|
|
keyIdx != keyEnd; ++keyIdx) {
|
|
|
|
float key = keys[keyIdx];
|
2011-04-12 10:18:44 +04:00
|
|
|
// FIXME (spec): The spec doesn't say what to do with
|
|
|
|
// out-of-range keyframes. We'll ignore them.
|
|
|
|
if (0.0f <= key && key <= 1.0f) {
|
2012-03-22 09:10:02 +04:00
|
|
|
KeyframeData *data = sortedKeyframes.AppendElement();
|
|
|
|
data->mKey = key;
|
|
|
|
data->mIndex = ruleIdx;
|
|
|
|
data->mRule = kfRule;
|
2011-04-12 10:18:44 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
sortedKeyframes.Sort(KeyframeDataComparator());
|
|
|
|
|
|
|
|
if (sortedKeyframes.Length() == 0) {
|
|
|
|
// no segments
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2011-04-23 05:36:23 +04:00
|
|
|
// Record the properties that are present in any keyframe rules we
|
|
|
|
// are using.
|
|
|
|
nsCSSPropertySet properties;
|
2011-04-12 10:18:44 +04:00
|
|
|
|
2012-08-22 19:56:38 +04:00
|
|
|
for (uint32_t kfIdx = 0, kfEnd = sortedKeyframes.Length();
|
2011-04-23 05:36:23 +04:00
|
|
|
kfIdx != kfEnd; ++kfIdx) {
|
2011-04-23 05:36:23 +04:00
|
|
|
css::Declaration *decl = sortedKeyframes[kfIdx].mRule->Declaration();
|
2012-08-22 19:56:38 +04:00
|
|
|
for (uint32_t propIdx = 0, propEnd = decl->Count();
|
2011-04-23 05:36:23 +04:00
|
|
|
propIdx != propEnd; ++propIdx) {
|
Bug 773296 - Part 2: Parse CSS variable declarations and store them on Declaration objects. p=ebassi,heycam r=dbaron
Patch co-authored by Emmanuele Bassi <ebassi@gmail.com>
This defines a CSSVariableDeclarations class that holds a set of
variable declarations. This is at the specified value stage, so values
can either be 'initial', 'inherit' or a token stream (which is what you
normally have). The variables are stored in a hash table. Although
it's a bit of a hack, we store 'initial' and 'inherit' using special
string values that can't be valid token streams (we use "!" and ";").
Declaration objects now can have two CSSVariableDeclarations objects
on them, to store normal and !important variable declarations. So that
we keep preserving the order of declarations on the object, we inflate
mOrder to store uint32_ts, where values from eCSSProperty_COUNT onwards
represent custom properties. mVariableOrder stores the names of the
variables corresponding to those entries in mOrder.
We also add a new nsCSSProperty value, eCSSPropertyExtra_variable, which
is used to represent any custom property name.
nsCSSProps::LookupProperty can return this value.
The changes to nsCSSParser are straightforward. Custom properties
are parsed and checked for syntactic validity (e.g. "var(a,)" being
invalid) and stored on the Declaration. We use nsCSSScanner's
recording ability to grab the unparsed CSS string corresponding to
the variable's value.
2013-12-12 06:09:40 +04:00
|
|
|
nsCSSProperty prop = decl->GetPropertyAt(propIdx);
|
|
|
|
if (prop != eCSSPropertyExtra_variable) {
|
|
|
|
// CSS Variables are not animatable
|
|
|
|
properties.AddProperty(prop);
|
|
|
|
}
|
2011-04-23 05:36:23 +04:00
|
|
|
}
|
2011-04-12 10:18:44 +04:00
|
|
|
}
|
|
|
|
|
2011-04-23 05:36:23 +04:00
|
|
|
for (nsCSSProperty prop = nsCSSProperty(0);
|
|
|
|
prop < eCSSProperty_COUNT_no_shorthands;
|
|
|
|
prop = nsCSSProperty(prop + 1)) {
|
|
|
|
if (!properties.HasProperty(prop) ||
|
|
|
|
nsCSSProps::kAnimTypeTable[prop] == eStyleAnimType_None) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2012-03-22 09:10:02 +04:00
|
|
|
// Build a list of the keyframes to use for this property. This
|
|
|
|
// means we need every keyframe with the property in it, except
|
|
|
|
// for those keyframes where a later keyframe with the *same key*
|
|
|
|
// also has the property.
|
2012-08-22 19:56:38 +04:00
|
|
|
AutoInfallibleTArray<uint32_t, 16> keyframesWithProperty;
|
2012-03-22 09:10:02 +04:00
|
|
|
float lastKey = 100.0f; // an invalid key
|
2012-08-22 19:56:38 +04:00
|
|
|
for (uint32_t kfIdx = 0, kfEnd = sortedKeyframes.Length();
|
2012-03-22 09:10:02 +04:00
|
|
|
kfIdx != kfEnd; ++kfIdx) {
|
|
|
|
KeyframeData &kf = sortedKeyframes[kfIdx];
|
|
|
|
if (!kf.mRule->Declaration()->HasProperty(prop)) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (kf.mKey == lastKey) {
|
|
|
|
// Replace previous occurrence of same key.
|
|
|
|
keyframesWithProperty[keyframesWithProperty.Length() - 1] = kfIdx;
|
|
|
|
} else {
|
|
|
|
keyframesWithProperty.AppendElement(kfIdx);
|
|
|
|
}
|
|
|
|
lastKey = kf.mKey;
|
|
|
|
}
|
|
|
|
|
2015-04-15 02:48:21 +03:00
|
|
|
AnimationProperty &propData = *destEffect->Properties().AppendElement();
|
2011-04-23 05:36:23 +04:00
|
|
|
propData.mProperty = prop;
|
|
|
|
|
2012-07-30 18:20:58 +04:00
|
|
|
KeyframeData *fromKeyframe = nullptr;
|
2015-10-18 08:24:48 +03:00
|
|
|
RefPtr<nsStyleContext> fromContext;
|
2011-04-23 05:36:23 +04:00
|
|
|
bool interpolated = true;
|
2012-08-22 19:56:38 +04:00
|
|
|
for (uint32_t wpIdx = 0, wpEnd = keyframesWithProperty.Length();
|
2012-03-22 09:10:02 +04:00
|
|
|
wpIdx != wpEnd; ++wpIdx) {
|
2012-08-22 19:56:38 +04:00
|
|
|
uint32_t kfIdx = keyframesWithProperty[wpIdx];
|
2011-04-23 05:36:23 +04:00
|
|
|
KeyframeData &toKeyframe = sortedKeyframes[kfIdx];
|
|
|
|
|
2015-10-18 08:24:48 +03:00
|
|
|
RefPtr<nsStyleContext> toContext =
|
2015-11-05 11:44:11 +03:00
|
|
|
resolvedStyles.Get(mPresContext, aStyleContext,
|
|
|
|
toKeyframe.mRule->Declaration());
|
2011-04-23 05:36:23 +04:00
|
|
|
|
|
|
|
if (fromKeyframe) {
|
|
|
|
interpolated = interpolated &&
|
2014-05-15 03:38:37 +04:00
|
|
|
BuildSegment(propData.mSegments, prop, src,
|
2011-04-23 05:36:23 +04:00
|
|
|
fromKeyframe->mKey, fromContext,
|
|
|
|
fromKeyframe->mRule->Declaration(),
|
|
|
|
toKeyframe.mKey, toContext);
|
|
|
|
} else {
|
|
|
|
if (toKeyframe.mKey != 0.0f) {
|
|
|
|
// There's no data for this property at 0%, so use the
|
|
|
|
// cascaded value above us.
|
2015-02-17 01:15:01 +03:00
|
|
|
if (!styleWithoutAnimation) {
|
|
|
|
styleWithoutAnimation = mPresContext->StyleSet()->
|
|
|
|
ResolveStyleWithoutAnimation(aTarget, aStyleContext,
|
2015-02-17 01:15:06 +03:00
|
|
|
eRestyle_AllHintsWithAnimations);
|
2015-02-17 01:15:01 +03:00
|
|
|
}
|
2011-04-23 05:36:23 +04:00
|
|
|
interpolated = interpolated &&
|
2014-05-15 03:38:37 +04:00
|
|
|
BuildSegment(propData.mSegments, prop, src,
|
2015-02-17 01:15:01 +03:00
|
|
|
0.0f, styleWithoutAnimation, nullptr,
|
2011-04-23 05:36:23 +04:00
|
|
|
toKeyframe.mKey, toContext);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
fromContext = toContext;
|
|
|
|
fromKeyframe = &toKeyframe;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (fromKeyframe->mKey != 1.0f) {
|
|
|
|
// There's no data for this property at 100%, so use the
|
|
|
|
// cascaded value above us.
|
2015-02-17 01:15:01 +03:00
|
|
|
if (!styleWithoutAnimation) {
|
|
|
|
styleWithoutAnimation = mPresContext->StyleSet()->
|
|
|
|
ResolveStyleWithoutAnimation(aTarget, aStyleContext,
|
2015-02-17 01:15:06 +03:00
|
|
|
eRestyle_AllHintsWithAnimations);
|
2015-02-17 01:15:01 +03:00
|
|
|
}
|
2011-04-23 05:36:23 +04:00
|
|
|
interpolated = interpolated &&
|
2014-05-15 03:38:37 +04:00
|
|
|
BuildSegment(propData.mSegments, prop, src,
|
2011-04-23 05:36:23 +04:00
|
|
|
fromKeyframe->mKey, fromContext,
|
|
|
|
fromKeyframe->mRule->Declaration(),
|
2015-02-17 01:15:01 +03:00
|
|
|
1.0f, styleWithoutAnimation);
|
2011-04-23 05:36:23 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
// If we failed to build any segments due to inability to
|
|
|
|
// interpolate, remove the property from the animation. (It's not
|
|
|
|
// clear if this is the right thing to do -- we could run some of
|
|
|
|
// the segments, but it's really not clear whether we should skip
|
|
|
|
// values (which?) or skip segments, so best to skip the whole
|
|
|
|
// thing for now.)
|
|
|
|
if (!interpolated) {
|
2015-04-15 02:48:21 +03:00
|
|
|
destEffect->Properties().RemoveElementAt(
|
|
|
|
destEffect->Properties().Length() - 1);
|
2011-04-23 05:36:23 +04:00
|
|
|
}
|
2011-04-12 10:18:44 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-04-23 05:36:23 +04:00
|
|
|
bool
|
|
|
|
nsAnimationManager::BuildSegment(InfallibleTArray<AnimationPropertySegment>&
|
|
|
|
aSegments,
|
|
|
|
nsCSSProperty aProperty,
|
2014-06-27 03:57:11 +04:00
|
|
|
const StyleAnimation& aAnimation,
|
2011-04-12 10:18:44 +04:00
|
|
|
float aFromKey, nsStyleContext* aFromContext,
|
|
|
|
mozilla::css::Declaration* aFromDeclaration,
|
2011-04-23 05:36:23 +04:00
|
|
|
float aToKey, nsStyleContext* aToContext)
|
2011-04-12 10:18:44 +04:00
|
|
|
{
|
2014-06-24 10:29:54 +04:00
|
|
|
StyleAnimationValue fromValue, toValue, dummyValue;
|
2011-04-23 05:36:23 +04:00
|
|
|
if (!ExtractComputedValueForTransition(aProperty, aFromContext, fromValue) ||
|
|
|
|
!ExtractComputedValueForTransition(aProperty, aToContext, toValue) ||
|
|
|
|
// Check that we can interpolate between these values
|
|
|
|
// (If this is ever a performance problem, we could add a
|
|
|
|
// CanInterpolate method, but it seems fine for now.)
|
2014-06-24 10:29:54 +04:00
|
|
|
!StyleAnimationValue::Interpolate(aProperty, fromValue, toValue,
|
|
|
|
0.5, dummyValue)) {
|
2011-04-23 05:36:23 +04:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
AnimationPropertySegment &segment = *aSegments.AppendElement();
|
2011-04-12 10:18:44 +04:00
|
|
|
|
2011-04-23 05:36:23 +04:00
|
|
|
segment.mFromValue = fromValue;
|
|
|
|
segment.mToValue = toValue;
|
2011-04-12 10:18:44 +04:00
|
|
|
segment.mFromKey = aFromKey;
|
|
|
|
segment.mToKey = aToKey;
|
|
|
|
const nsTimingFunction *tf;
|
|
|
|
if (aFromDeclaration &&
|
|
|
|
aFromDeclaration->HasProperty(eCSSProperty_animation_timing_function)) {
|
2013-02-17 01:51:02 +04:00
|
|
|
tf = &aFromContext->StyleDisplay()->mAnimations[0].GetTimingFunction();
|
2011-04-12 10:18:44 +04:00
|
|
|
} else {
|
|
|
|
tf = &aAnimation.GetTimingFunction();
|
|
|
|
}
|
|
|
|
segment.mTimingFunction.Init(*tf);
|
|
|
|
|
2011-04-23 05:36:23 +04:00
|
|
|
return true;
|
2011-04-12 10:18:44 +04:00
|
|
|
}
|
|
|
|
|
2015-04-01 01:05:54 +03:00
|
|
|
/* static */ void
|
|
|
|
nsAnimationManager::UpdateCascadeResults(
|
|
|
|
nsStyleContext* aStyleContext,
|
2015-04-21 04:22:10 +03:00
|
|
|
AnimationCollection* aElementAnimations)
|
2015-04-01 01:05:54 +03:00
|
|
|
{
|
|
|
|
/*
|
2016-01-06 05:04:04 +03:00
|
|
|
* Look for compositor-animatable properties that are set in things that
|
2015-04-01 01:05:54 +03:00
|
|
|
* override animations.
|
|
|
|
*/
|
|
|
|
nsCSSPropertySet propertiesOverridden;
|
2016-01-06 05:04:04 +03:00
|
|
|
EffectCompositor::GetOverriddenProperties(aStyleContext,
|
|
|
|
propertiesOverridden);
|
2015-04-01 01:05:54 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Set mWinsInCascade based both on what is overridden at levels
|
|
|
|
* higher than animations and based on one animation overriding
|
|
|
|
* another.
|
|
|
|
*
|
|
|
|
* We iterate from the last animation to the first, just like we do
|
2015-04-21 04:22:10 +03:00
|
|
|
* when calling ComposeStyle from AnimationCollection::EnsureStyleRuleFor.
|
|
|
|
* Later animations override earlier ones, so we add properties to the set
|
|
|
|
* of overridden properties as we encounter them, if the animation is
|
2015-04-01 01:05:54 +03:00
|
|
|
* currently in effect.
|
|
|
|
*/
|
|
|
|
|
|
|
|
bool changed = false;
|
2015-04-21 04:22:10 +03:00
|
|
|
for (size_t animIdx = aElementAnimations->mAnimations.Length();
|
|
|
|
animIdx-- != 0; ) {
|
2015-04-21 04:22:10 +03:00
|
|
|
CSSAnimation* anim =
|
|
|
|
aElementAnimations->mAnimations[animIdx]->AsCSSAnimation();
|
2015-04-30 16:06:43 +03:00
|
|
|
KeyframeEffectReadOnly* effect = anim->GetEffect();
|
2015-04-01 01:05:54 +03:00
|
|
|
|
2015-04-21 04:22:10 +03:00
|
|
|
anim->mInEffectForCascadeResults = anim->IsInEffect();
|
2015-04-01 01:05:54 +03:00
|
|
|
|
2015-04-15 02:48:21 +03:00
|
|
|
if (!effect) {
|
2015-04-01 01:05:54 +03:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2015-04-15 02:48:21 +03:00
|
|
|
for (size_t propIdx = 0, propEnd = effect->Properties().Length();
|
2015-04-01 01:05:54 +03:00
|
|
|
propIdx != propEnd; ++propIdx) {
|
2015-04-15 02:48:21 +03:00
|
|
|
AnimationProperty& prop = effect->Properties()[propIdx];
|
2015-04-01 01:05:54 +03:00
|
|
|
// We only bother setting mWinsInCascade for properties that we
|
|
|
|
// can animate on the compositor.
|
|
|
|
if (nsCSSProps::PropHasFlags(prop.mProperty,
|
|
|
|
CSS_PROPERTY_CAN_ANIMATE_ON_COMPOSITOR)) {
|
|
|
|
bool newWinsInCascade =
|
|
|
|
!propertiesOverridden.HasProperty(prop.mProperty);
|
|
|
|
if (newWinsInCascade != prop.mWinsInCascade) {
|
|
|
|
changed = true;
|
|
|
|
}
|
|
|
|
prop.mWinsInCascade = newWinsInCascade;
|
|
|
|
|
2015-04-21 04:22:10 +03:00
|
|
|
if (prop.mWinsInCascade && anim->mInEffectForCascadeResults) {
|
2015-04-01 01:05:54 +03:00
|
|
|
// This animation is in effect right now, so it overrides
|
|
|
|
// earlier animations. (For animations that aren't in effect,
|
|
|
|
// we set mWinsInCascade as though they were, but they don't
|
|
|
|
// suppress animations lower in the cascade.)
|
|
|
|
propertiesOverridden.AddProperty(prop.mProperty);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-08-18 10:11:55 +03:00
|
|
|
// If there is any change in the cascade result, update animations on layers
|
|
|
|
// with the winning animations.
|
2015-04-01 01:05:54 +03:00
|
|
|
if (changed) {
|
2015-08-18 10:11:55 +03:00
|
|
|
aElementAnimations->RequestRestyle(AnimationCollection::RestyleType::Layer);
|
2015-04-01 01:05:54 +03:00
|
|
|
}
|
|
|
|
}
|