gecko-dev/layout/style/nsTransitionManager.h

458 строки
17 KiB
C
Исходник Обычный вид История

/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
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/. */
/* Code to start and animate CSS transitions. */
#ifndef nsTransitionManager_h_
#define nsTransitionManager_h_
#include "mozilla/ComputedTiming.h"
#include "mozilla/ContentEvents.h"
#include "mozilla/EffectCompositor.h" // For EffectCompositor::CascadeLevel
#include "mozilla/MemoryReporting.h"
#include "mozilla/dom/Animation.h"
#include "mozilla/dom/KeyframeEffectReadOnly.h"
#include "AnimationCommon.h"
#include "nsCSSProps.h"
class nsIGlobalObject;
class nsStyleContext;
class nsPresContext;
class nsCSSPropertyIDSet;
namespace mozilla {
enum class CSSPseudoElementType : uint8_t;
class GeckoStyleContext;
struct Keyframe;
struct StyleTransition;
class ServoStyleContext;
} // namespace mozilla
/*****************************************************************************
* Per-Element data *
*****************************************************************************/
namespace mozilla {
struct ElementPropertyTransition : public dom::KeyframeEffectReadOnly
{
ElementPropertyTransition(nsIDocument* aDocument,
Maybe<OwningAnimationTarget>& aTarget,
const TimingParams &aTiming,
AnimationValue aStartForReversingTest,
double aReversePortion,
const KeyframeEffectParams& aEffectOptions)
: dom::KeyframeEffectReadOnly(aDocument, aTarget, aTiming, aEffectOptions)
, mStartForReversingTest(aStartForReversingTest)
, mReversePortion(aReversePortion)
{ }
ElementPropertyTransition* AsTransition() override { return this; }
const ElementPropertyTransition* AsTransition() const override
{
return this;
}
nsCSSPropertyID TransitionProperty() const {
MOZ_ASSERT(mKeyframes.Length() == 2,
"Transitions should have exactly two animation keyframes. "
"Perhaps we are using an un-initialized transition?");
MOZ_ASSERT(mKeyframes[0].mPropertyValues.Length() == 1,
"Transitions should have exactly one property in their first "
"frame");
return mKeyframes[0].mPropertyValues[0].mProperty;
}
AnimationValue ToValue() const {
// If we failed to generate properties from the transition frames,
// return a null value but also show a warning since we should be
// detecting that kind of situation in advance and not generating a
// transition in the first place.
if (mProperties.Length() < 1 ||
mProperties[0].mSegments.Length() < 1) {
NS_WARNING("Failed to generate transition property values");
return AnimationValue();
}
return mProperties[0].mSegments[0].mToValue;
}
// This is the start value to be used for a check for whether a
// transition is being reversed. Normally the same as
// mProperties[0].mSegments[0].mFromValue, except when this transition
// started as the reversal of another in-progress transition.
// Needed so we can handle two reverses in a row.
AnimationValue mStartForReversingTest;
// Likewise, the portion (in value space) of the "full" reversed
// transition that we're actually covering. For example, if a :hover
// effect has a transition that moves the element 10px to the right
// (by changing 'left' from 0px to 10px), and the mouse moves in to
// the element (starting the transition) but then moves out after the
// transition has advanced 4px, the second transition (from 10px/4px
// to 0px) will have mReversePortion of 0.4. (If the mouse then moves
// in again when the transition is back to 2px, the mReversePortion
// for the third transition (from 0px/2px to 10px) will be 0.8.
double mReversePortion;
// Compute the portion of the *value* space that we should be through
// at the current time. (The input to the transition timing function
// has time units, the output has value units.)
double CurrentValuePortion() const;
// For a new transition interrupting an existing transition on the
// compositor, update the start value to match the value of the replaced
// transitions at the current time.
void UpdateStartValueFromReplacedTransition();
struct ReplacedTransitionProperties {
TimeDuration mStartTime;
double mPlaybackRate;
TimingParams mTiming;
Maybe<ComputedTimingFunction> mTimingFunction;
AnimationValue mFromValue, mToValue;
};
Maybe<ReplacedTransitionProperties> mReplacedTransition;
};
namespace dom {
class CSSTransition final : public Animation
{
public:
explicit CSSTransition(nsIGlobalObject* aGlobal)
: dom::Animation(aGlobal)
, mPreviousTransitionPhase(TransitionPhase::Idle)
Bug 1203009 part 3 - Add mNeedsNewAnimationIndexWhenRun flag to CSSAnimation and CSSTransition; r=heycam In the new composite order arrangement CSSAnimations and CSSTransition have the following life-cycle: 1. Animation created by markup => composite order determined by markup (e.g. CSS animations use tree order and animation-name order; CSS transitions use transition trigger order) 2. Animation cancelled by changing markup => composite order is undefined 3. Animation is played again using the API => composite order is defined by when the animation is first played. Another way of saying this is that, at the point when the animation is played, it is appended to the "global animation list". 4. Animation is subsequently cancelled / played => no change We need a way to know when we are going from 2 to 3. It would seem like we could do that by setting mAnimationIndex to some sentinel value while it is in 2. However, even when in 2, although the spec doesn't define the composite order animations at this point (from an API point of view you can't access these objects and they don't contribute to style so it doesn't need to be defined), we sometimes will need to establish an order. This can happen, for example, when an animation queues events and then is later cancelled before the events are dispatched. Because we sort events based on their associated animation at the time of dispatch (for performance reasons) we need a deterministic order for these idle animations. We do that (in a subsequent patch in this series) by setting mAnimationIndex when we transition from 1 to 2. That is, these idle animations are effectively ordered by when they became idle (which always happens in a deterministic fashion).
2015-09-15 05:20:33 +03:00
, mNeedsNewAnimationIndexWhenRun(false)
, mTransitionProperty(eCSSProperty_UNKNOWN)
{
}
JSObject* WrapObject(JSContext* aCx,
JS::Handle<JSObject*> aGivenProto) override;
CSSTransition* AsCSSTransition() override { return this; }
const CSSTransition* AsCSSTransition() const override { return this; }
// CSSTransition interface
void GetTransitionProperty(nsString& aRetVal) const;
// Animation interface overrides
AnimationPlayState PlayStateFromJS() const override;
bool PendingFromJS() const override;
void PlayFromJS(ErrorResult& aRv) override;
// A variant of Play() that avoids posting style updates since this method
// is expected to be called whilst already updating style.
void PlayFromStyle()
{
ErrorResult rv;
PlayNoUpdate(rv, Animation::LimitBehavior::Continue);
// play() should not throw when LimitBehavior is Continue
MOZ_ASSERT(!rv.Failed(), "Unexpected exception playing transition");
}
void CancelFromStyle() override
{
// The animation index to use for compositing will be established when
// this transition next transitions out of the idle state but we still
// update it now so that the sort order of this transition remains
// defined until that moment.
//
// See longer explanation in CSSAnimation::CancelFromStyle.
mAnimationIndex = sNextAnimationIndex++;
mNeedsNewAnimationIndexWhenRun = true;
Animation::CancelFromStyle();
// It is important we do this *after* calling CancelFromStyle().
// This is because CancelFromStyle() will end up posting a restyle and
// that restyle should target the *transitions* level of the cascade.
// However, once we clear the owning element, CascadeLevel() will begin
// returning CascadeLevel::Animations.
mOwningElement = OwningElementRef();
}
void SetEffectFromStyle(AnimationEffectReadOnly* aEffect);
Bug 1180125 part 7 - Queue transition events from CSSTransition::Tick; r=dbaron This patch moves the logic for queueing events out of the logic for flushing transitions making it a separate step. It still doesn't delay the dispatch of those events into a separate step, however. That is done in a subsequent patch. This patch also makes sure to clear any queued events when the nsPresShell that owns the transition manager is destroyed. We don't expect CSSTransition::Tick to be called anywhere except nsTransitionManger::FlushTransitions so there shouldn't be any orphaned events but for completeness it seems best to add this now. (Later, when we tick transitions from their timeline we will need this.) This patch introduces a separate flag to CSSTransition for tracking if a transition is newly-finished so we can correctly dispatch the transitionend event. Although, this may seem to be redundant with the "IsFinishedTransition" we also track, that state will soon be removed in bug 1181392 and hence this flag will be needed then. Note that Animation already has flags mIsPreviousStateFinished and mFinishedAtLastComposeStyle which would appear to be similar however, - mIsPreviousStateFinished will be removed in bug 1178665 and is updated more often than we queue events so it is not useful here. - mFinishedAtLastComposeStyle is used to determine if we can throttle a style update and is also updated more frequently than we queue events and hence can't be used here. Once we guarantee one call to Tick() per frame we may be able to simplify this by tracking "state on last tick" but for now we need this additional flag on CSSTransition. CSSAnimation has a similar flag for this (mPreviousPhaseOrIteration) which we may be able to unify at the same point.
2015-07-29 04:57:40 +03:00
void Tick() override;
nsCSSPropertyID TransitionProperty() const;
AnimationValue ToValue() const;
bool HasLowerCompositeOrderThan(const CSSTransition& aOther) const;
EffectCompositor::CascadeLevel CascadeLevel() const override
{
return IsTiedToMarkup() ?
EffectCompositor::CascadeLevel::Transitions :
EffectCompositor::CascadeLevel::Animations;
}
void SetCreationSequence(uint64_t aIndex)
{
MOZ_ASSERT(IsTiedToMarkup());
mAnimationIndex = aIndex;
}
// Sets the owning element which is used for determining the composite
// oder of CSSTransition objects generated from CSS markup.
//
// @see mOwningElement
void SetOwningElement(const OwningElementRef& aElement)
{
mOwningElement = aElement;
}
// True for transitions that are generated from CSS markup and continue to
// reflect changes to that markup.
bool IsTiedToMarkup() const { return mOwningElement.IsSet(); }
// Return the animation current time based on a given TimeStamp, a given
// start time and a given playbackRate on a given timeline. This is useful
// when we estimate the current animated value running on the compositor
// because the animation on the compositor may be running ahead while
// main-thread is busy.
static Nullable<TimeDuration> GetCurrentTimeAt(
const DocumentTimeline& aTimeline,
const TimeStamp& aBaseTime,
const TimeDuration& aStartTime,
double aPlaybackRate);
void MaybeQueueCancelEvent(StickyTimeDuration aActiveTime) override {
QueueEvents(aActiveTime);
}
protected:
virtual ~CSSTransition()
{
MOZ_ASSERT(!mOwningElement.IsSet(), "Owning element should be cleared "
"before a CSS transition is destroyed");
}
// Animation overrides
void UpdateTiming(SeekFlag aSeekFlag,
SyncNotifyFlag aSyncNotifyFlag) override;
void QueueEvents(StickyTimeDuration activeTime = StickyTimeDuration());
Bug 1180125 part 7 - Queue transition events from CSSTransition::Tick; r=dbaron This patch moves the logic for queueing events out of the logic for flushing transitions making it a separate step. It still doesn't delay the dispatch of those events into a separate step, however. That is done in a subsequent patch. This patch also makes sure to clear any queued events when the nsPresShell that owns the transition manager is destroyed. We don't expect CSSTransition::Tick to be called anywhere except nsTransitionManger::FlushTransitions so there shouldn't be any orphaned events but for completeness it seems best to add this now. (Later, when we tick transitions from their timeline we will need this.) This patch introduces a separate flag to CSSTransition for tracking if a transition is newly-finished so we can correctly dispatch the transitionend event. Although, this may seem to be redundant with the "IsFinishedTransition" we also track, that state will soon be removed in bug 1181392 and hence this flag will be needed then. Note that Animation already has flags mIsPreviousStateFinished and mFinishedAtLastComposeStyle which would appear to be similar however, - mIsPreviousStateFinished will be removed in bug 1178665 and is updated more often than we queue events so it is not useful here. - mFinishedAtLastComposeStyle is used to determine if we can throttle a style update and is also updated more frequently than we queue events and hence can't be used here. Once we guarantee one call to Tick() per frame we may be able to simplify this by tracking "state on last tick" but for now we need this additional flag on CSSTransition. CSSAnimation has a similar flag for this (mPreviousPhaseOrIteration) which we may be able to unify at the same point.
2015-07-29 04:57:40 +03:00
enum class TransitionPhase;
// The (pseudo-)element whose computed transition-property refers to this
// transition (if any).
//
// This is used for determining the relative composite order of transitions
// generated from CSS markup.
//
// Typically this will be the same as the target element of the keyframe
// effect associated with this transition. However, it can differ in the
// following circumstances:
//
// a) If script removes or replaces the effect of this transition,
// b) If this transition is cancelled (e.g. by updating the
// transition-property or removing the owning element from the document),
// c) If this object is generated from script using the CSSTransition
// constructor.
//
// For (b) and (c) the owning element will return !IsSet().
OwningElementRef mOwningElement;
Bug 1180125 part 7 - Queue transition events from CSSTransition::Tick; r=dbaron This patch moves the logic for queueing events out of the logic for flushing transitions making it a separate step. It still doesn't delay the dispatch of those events into a separate step, however. That is done in a subsequent patch. This patch also makes sure to clear any queued events when the nsPresShell that owns the transition manager is destroyed. We don't expect CSSTransition::Tick to be called anywhere except nsTransitionManger::FlushTransitions so there shouldn't be any orphaned events but for completeness it seems best to add this now. (Later, when we tick transitions from their timeline we will need this.) This patch introduces a separate flag to CSSTransition for tracking if a transition is newly-finished so we can correctly dispatch the transitionend event. Although, this may seem to be redundant with the "IsFinishedTransition" we also track, that state will soon be removed in bug 1181392 and hence this flag will be needed then. Note that Animation already has flags mIsPreviousStateFinished and mFinishedAtLastComposeStyle which would appear to be similar however, - mIsPreviousStateFinished will be removed in bug 1178665 and is updated more often than we queue events so it is not useful here. - mFinishedAtLastComposeStyle is used to determine if we can throttle a style update and is also updated more frequently than we queue events and hence can't be used here. Once we guarantee one call to Tick() per frame we may be able to simplify this by tracking "state on last tick" but for now we need this additional flag on CSSTransition. CSSAnimation has a similar flag for this (mPreviousPhaseOrIteration) which we may be able to unify at the same point.
2015-07-29 04:57:40 +03:00
// The 'transition phase' used to determine which transition events need
// to be queued on this tick.
// See: https://drafts.csswg.org/css-transitions-2/#transition-phase
enum class TransitionPhase {
Idle = static_cast<int>(ComputedTiming::AnimationPhase::Idle),
Before = static_cast<int>(ComputedTiming::AnimationPhase::Before),
Active = static_cast<int>(ComputedTiming::AnimationPhase::Active),
After = static_cast<int>(ComputedTiming::AnimationPhase::After),
Pending
};
TransitionPhase mPreviousTransitionPhase;
Bug 1203009 part 3 - Add mNeedsNewAnimationIndexWhenRun flag to CSSAnimation and CSSTransition; r=heycam In the new composite order arrangement CSSAnimations and CSSTransition have the following life-cycle: 1. Animation created by markup => composite order determined by markup (e.g. CSS animations use tree order and animation-name order; CSS transitions use transition trigger order) 2. Animation cancelled by changing markup => composite order is undefined 3. Animation is played again using the API => composite order is defined by when the animation is first played. Another way of saying this is that, at the point when the animation is played, it is appended to the "global animation list". 4. Animation is subsequently cancelled / played => no change We need a way to know when we are going from 2 to 3. It would seem like we could do that by setting mAnimationIndex to some sentinel value while it is in 2. However, even when in 2, although the spec doesn't define the composite order animations at this point (from an API point of view you can't access these objects and they don't contribute to style so it doesn't need to be defined), we sometimes will need to establish an order. This can happen, for example, when an animation queues events and then is later cancelled before the events are dispatched. Because we sort events based on their associated animation at the time of dispatch (for performance reasons) we need a deterministic order for these idle animations. We do that (in a subsequent patch in this series) by setting mAnimationIndex when we transition from 1 to 2. That is, these idle animations are effectively ordered by when they became idle (which always happens in a deterministic fashion).
2015-09-15 05:20:33 +03:00
// When true, indicates that when this transition next leaves the idle state,
// its animation index should be updated.
bool mNeedsNewAnimationIndexWhenRun;
// Store the transition property and to-value here since we need that
// information in order to determine if there is an existing transition
// for a given style change. We can't store that information on the
// ElementPropertyTransition (effect) however since it can be replaced
// using the Web Animations API.
nsCSSPropertyID mTransitionProperty;
AnimationValue mTransitionToValue;
};
} // namespace dom
template <>
struct AnimationTypeTraits<dom::CSSTransition>
{
static nsAtom* ElementPropertyAtom()
{
return nsGkAtoms::transitionsProperty;
}
static nsAtom* BeforePropertyAtom()
{
return nsGkAtoms::transitionsOfBeforeProperty;
}
static nsAtom* AfterPropertyAtom()
{
return nsGkAtoms::transitionsOfAfterProperty;
}
};
struct TransitionEventInfo {
Bug 1207245 - part 6 - rename nsRefPtr<T> to RefPtr<T>; r=ehsan; a=Tomcat The bulk of this commit was generated with a script, executed at the top level of a typical source code checkout. The only non-machine-generated part was modifying MFBT's moz.build to reflect the new naming. CLOSED TREE makes big refactorings like this a piece of cake. # The main substitution. find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \ xargs perl -p -i -e ' s/nsRefPtr\.h/RefPtr\.h/g; # handle includes s/nsRefPtr ?</RefPtr</g; # handle declarations and variables ' # Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h. perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h # Handle nsRefPtr.h itself, a couple places that define constructors # from nsRefPtr, and code generators specially. We do this here, rather # than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename # things like nsRefPtrHashtable. perl -p -i -e 's/nsRefPtr/RefPtr/g' \ mfbt/nsRefPtr.h \ xpcom/glue/nsCOMPtr.h \ xpcom/base/OwningNonNull.h \ ipc/ipdl/ipdl/lower.py \ ipc/ipdl/ipdl/builtin.py \ dom/bindings/Codegen.py \ python/lldbutils/lldbutils/utils.py # In our indiscriminate substitution above, we renamed # nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up. find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \ xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g' if [ -d .git ]; then git mv mfbt/nsRefPtr.h mfbt/RefPtr.h else hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h fi --HG-- rename : mfbt/nsRefPtr.h => mfbt/RefPtr.h
2015-10-18 08:24:48 +03:00
RefPtr<dom::Element> mElement;
RefPtr<dom::Animation> mAnimation;
InternalTransitionEvent mEvent;
TimeStamp mTimeStamp;
TransitionEventInfo(dom::Element* aElement,
CSSPseudoElementType aPseudoType,
EventMessage aMessage,
nsCSSPropertyID aProperty,
StickyTimeDuration aDuration,
const TimeStamp& aTimeStamp,
dom::Animation* aAnimation)
: mElement(aElement)
, mAnimation(aAnimation)
, mEvent(true, aMessage)
, mTimeStamp(aTimeStamp)
{
// XXX Looks like nobody initialize WidgetEvent::time
mEvent.mPropertyName =
NS_ConvertUTF8toUTF16(nsCSSProps::GetStringValue(aProperty));
mEvent.mElapsedTime = aDuration.ToSeconds();
mEvent.mPseudoElement =
AnimationCollection<dom::CSSTransition>::PseudoTypeAsString(aPseudoType);
}
// InternalTransitionEvent doesn't support copy-construction, so we need
// to ourselves in order to work with nsTArray
TransitionEventInfo(const TransitionEventInfo& aOther)
: mElement(aOther.mElement)
, mAnimation(aOther.mAnimation)
, mEvent(aOther.mEvent)
, mTimeStamp(aOther.mTimeStamp)
{
mEvent.AssignTransitionEventData(aOther.mEvent, false);
}
};
} // namespace mozilla
class nsTransitionManager final
: public mozilla::CommonAnimationManager<mozilla::dom::CSSTransition>
{
public:
explicit nsTransitionManager(nsPresContext *aPresContext)
: mozilla::CommonAnimationManager<mozilla::dom::CSSTransition>(aPresContext)
, mInAnimationOnlyStyleUpdate(false)
{
}
NS_INLINE_DECL_CYCLE_COLLECTING_NATIVE_REFCOUNTING(nsTransitionManager)
NS_DECL_CYCLE_COLLECTION_NATIVE_CLASS(nsTransitionManager)
typedef mozilla::AnimationCollection<mozilla::dom::CSSTransition>
CSSTransitionCollection;
/**
* StyleContextChanged
*
* To be called from RestyleManager::TryInitiatingTransition when the
* style of an element has changed, to initiate transitions from
* that style change. For style contexts with :before and :after
* pseudos, aElement is expected to be the generated before/after
* element.
*
* It may modify the new style context (by replacing
* *aNewStyleContext) to cover up some of the changes for the duration
* of the restyling of descendants. If it does, this function will
* take care of causing the necessary restyle afterwards.
*/
void StyleContextChanged(mozilla::dom::Element *aElement,
mozilla::GeckoStyleContext* aOldStyleContext,
RefPtr<mozilla::GeckoStyleContext>* aNewStyleContext /* inout */);
/**
* Update transitions for stylo.
*/
bool UpdateTransitions(
mozilla::dom::Element *aElement,
mozilla::CSSPseudoElementType aPseudoType,
const mozilla::ServoStyleContext* aOldStyle,
const mozilla::ServoStyleContext* aNewStyle);
Bug 1144410 - Remove finished transitions when a frame transitions away from being display:none. r=birtles 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. --HG-- extra : transplant_source : %B4%A5%5Ck%E1%B7%F5Et%CF%9B%9F%40%97c%C5NM%D3%A8
2015-04-27 05:20:19 +03:00
/**
* When we're resolving style for an element that previously didn't have
* style, we might have some old finished transitions for it, if,
* say, it was display:none for a while, but previously displayed.
*
* This method removes any finished transitions that don't match the
* new style.
*/
void PruneCompletedTransitions(mozilla::dom::Element* aElement,
mozilla::CSSPseudoElementType aPseudoType,
mozilla::GeckoStyleContext* aNewStyleContext);
Bug 1144410 - Remove finished transitions when a frame transitions away from being display:none. r=birtles 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. --HG-- extra : transplant_source : %B4%A5%5Ck%E1%B7%F5Et%CF%9B%9F%40%97c%C5NM%D3%A8
2015-04-27 05:20:19 +03:00
void SetInAnimationOnlyStyleUpdate(bool aInAnimationOnlyUpdate) {
mInAnimationOnlyStyleUpdate = aInAnimationOnlyUpdate;
}
bool InAnimationOnlyStyleUpdate() const {
return mInAnimationOnlyStyleUpdate;
}
Bug 1180125 part 7 - Queue transition events from CSSTransition::Tick; r=dbaron This patch moves the logic for queueing events out of the logic for flushing transitions making it a separate step. It still doesn't delay the dispatch of those events into a separate step, however. That is done in a subsequent patch. This patch also makes sure to clear any queued events when the nsPresShell that owns the transition manager is destroyed. We don't expect CSSTransition::Tick to be called anywhere except nsTransitionManger::FlushTransitions so there shouldn't be any orphaned events but for completeness it seems best to add this now. (Later, when we tick transitions from their timeline we will need this.) This patch introduces a separate flag to CSSTransition for tracking if a transition is newly-finished so we can correctly dispatch the transitionend event. Although, this may seem to be redundant with the "IsFinishedTransition" we also track, that state will soon be removed in bug 1181392 and hence this flag will be needed then. Note that Animation already has flags mIsPreviousStateFinished and mFinishedAtLastComposeStyle which would appear to be similar however, - mIsPreviousStateFinished will be removed in bug 1178665 and is updated more often than we queue events so it is not useful here. - mFinishedAtLastComposeStyle is used to determine if we can throttle a style update and is also updated more frequently than we queue events and hence can't be used here. Once we guarantee one call to Tick() per frame we may be able to simplify this by tracking "state on last tick" but for now we need this additional flag on CSSTransition. CSSAnimation has a similar flag for this (mPreviousPhaseOrIteration) which we may be able to unify at the same point.
2015-07-29 04:57:40 +03:00
void QueueEvent(mozilla::TransitionEventInfo&& aEventInfo)
{
mEventDispatcher.QueueEvent(
mozilla::Forward<mozilla::TransitionEventInfo>(aEventInfo));
}
2016-02-10 16:17:05 +03:00
void DispatchEvents()
{
RefPtr<nsTransitionManager> kungFuDeathGrip(this);
mEventDispatcher.DispatchEvents(mPresContext);
}
void SortEvents() { mEventDispatcher.SortEvents(); }
Bug 1180125 part 7 - Queue transition events from CSSTransition::Tick; r=dbaron This patch moves the logic for queueing events out of the logic for flushing transitions making it a separate step. It still doesn't delay the dispatch of those events into a separate step, however. That is done in a subsequent patch. This patch also makes sure to clear any queued events when the nsPresShell that owns the transition manager is destroyed. We don't expect CSSTransition::Tick to be called anywhere except nsTransitionManger::FlushTransitions so there shouldn't be any orphaned events but for completeness it seems best to add this now. (Later, when we tick transitions from their timeline we will need this.) This patch introduces a separate flag to CSSTransition for tracking if a transition is newly-finished so we can correctly dispatch the transitionend event. Although, this may seem to be redundant with the "IsFinishedTransition" we also track, that state will soon be removed in bug 1181392 and hence this flag will be needed then. Note that Animation already has flags mIsPreviousStateFinished and mFinishedAtLastComposeStyle which would appear to be similar however, - mIsPreviousStateFinished will be removed in bug 1178665 and is updated more often than we queue events so it is not useful here. - mFinishedAtLastComposeStyle is used to determine if we can throttle a style update and is also updated more frequently than we queue events and hence can't be used here. Once we guarantee one call to Tick() per frame we may be able to simplify this by tracking "state on last tick" but for now we need this additional flag on CSSTransition. CSSAnimation has a similar flag for this (mPreviousPhaseOrIteration) which we may be able to unify at the same point.
2015-07-29 04:57:40 +03:00
void ClearEventQueue() { mEventDispatcher.ClearEventQueue(); }
protected:
virtual ~nsTransitionManager() {}
typedef nsTArray<RefPtr<mozilla::dom::CSSTransition>>
OwningCSSTransitionPtrArray;
// Update transitions. This will start new transitions,
// replace existing transitions, and stop existing transitions
// as needed. aDisp and aElement must be non-null.
// aElementTransitions is the collection of current transitions, and it
// could be a nullptr if we don't have any transitions.
template<typename StyleType> bool
DoUpdateTransitions(const nsStyleDisplay* aDisp,
mozilla::dom::Element* aElement,
mozilla::CSSPseudoElementType aPseudoType,
CSSTransitionCollection*& aElementTransitions,
StyleType aOldStyle,
StyleType aNewStyle);
template<typename StyleType> void
ConsiderInitiatingTransition(nsCSSPropertyID aProperty,
const mozilla::StyleTransition& aTransition,
mozilla::dom::Element* aElement,
mozilla::CSSPseudoElementType aPseudoType,
CSSTransitionCollection*& aElementTransitions,
StyleType aOldStyle,
StyleType aNewStyle,
bool* aStartedAny,
nsCSSPropertyIDSet* aWhichStarted);
bool mInAnimationOnlyStyleUpdate;
mozilla::DelayedEventDispatcher<mozilla::TransitionEventInfo>
mEventDispatcher;
};
#endif /* !defined(nsTransitionManager_h_) */