- OverflowChangedTracker::AddFrame now accepts an enumerated type parameter to
indicate if the overflow areas of children have changed (CHILDREN_CHANGED),
the overflow areas of the children have changed and the parent have changed
(CHILDREN_AND_PARENT_CHANGED), or if only the transform has changed
(TRANSFORM_CHANGED).
- OverflowChangedTracker::Flush no longer falls back to calling
nsIFrame::UpdateOverflow when a frame lacks a PreTransformOverflowAreas
property.
- Added an additional change hint, nsChangeHint_ChildrenOnlyTransform, which
results in TRANSFORM_CHANGED being passed in to
OverflowChangedTracker::AddFrame.
- In nsIFrame::FinishAndStoreOverflow, the passed in overflow is now stored as
the InitialTransformProperty for elements that are IsTransformed().
- Partially corrected Bug 926155, by only calling
OverflowChangedTracker::AddFrame on parents of the sticky element during
StickyScrollContainer::UpdatePositions, using CHILDREN_CHANGED.
This patch was mostly generated with the following command:
find . -name "*.h" -o -name "*.cpp" | xargs sed -e '/WrapObject(JSContext/ {; N; s/\(WrapObject(JSContext *\* *a\{0,1\}[Cc]x\),\n\{0,1\} *JS::Handle<JSObject\*> a\{0,1\}[sS]cope/\1/ ; }' -i ""
and then reverting the changes that made to
dom/bindings/BindingUtils.h, since those WrapObject methods are not
the ones we're trying to change here, plus a bunch of manual fixups
for cases that this command did not catch (including all the callsites
of WrapObject()).
This patch was mostly generated with this command:
find . -name "*.h" -o -name "*.cpp" | xargs sed -e 's/Binding::Wrap(aCx, aScope, this/Binding::Wrap(aCx, this/' -e 's/Binding_workers::Wrap(aCx, aScope, this/Binding_workers::Wrap(aCx, this/' -e 's/Binding::Wrap(cx, scope, this/Binding::Wrap(cx, this/' -i ""
plus a few manual fixes to dom/bindings/Codegen.py, js/xpconnect/src/event_impl_gen.py, and a few C++ files that were not caught in the search-and-replace above.
- OverflowChangedTracker::AddFrame now accepts an enumerated type parameter to
indicate if the overflow areas of children have changed (CHILDREN_CHANGED) or
if the transform has changed (TRANSFORM_CHANGED).
- OverflowChangedTracker::Flush no longer falls back to calling
nsIFrame::UpdateOverflow when a frame lacks a PreTransformOverflowAreas
property.
- Added an additional change hint, nsChangeHint_ChildrenOnlyTransform, which
results in TRANSFORM_CHANGED being passed in to
OverflowChangedTracker::AddFrame.
- In nsIFrame::FinishAndStoreOverflow, the passed in overflow is now stored as
the InitialTransformProperty for elements that are IsTransformed().
- Partially corrected Bug 926155, by only calling
OverflowChangedTracker::AddFrame on parents of the sticky element during
StickyScrollContainer::UpdatePositions, using CHILDREN_CHANGED.
Tests for animation list handling on the compositor thread. Some checks are
currently marked todo_is because they depend on Bug 980769 in order to pass.
This patch takes the compareTransform utility methods and makes them more
generic so they can be used for testing opacity too (the other property
currently animated on the compositor thread).
The naming omta_is and omta_is_approx is intended to mirror is and is_approx in
test_animations.html.
This patch adds an additional mochitest for specifically targetting CSS
Animations that run on the compositor thread. The content of the test mimicks
test_animations.html but using properties whose animations are expected to run
on the compositor thread.
Since off-main thread animation (OMTA) is not available on all platforms we
define a common wrapper function that runs OMTA tests only when available. This
patch further performs an internal check of basic OMTA operation so that
only a single error is produced if OMTA is unexpectedly unavailable.
Typical usage is:
SimpleTest.waitForExplicitFinish();
runOMTATest(function() {
... test code ...
SimpleTest.finish();
},
SimpleTest.finish);
This can be easily wrapped with promises if needed but does not require using
promises.
The calls to waitForExplicitFinish and finish are not performed automatically
since this function may be integrated with test suites that do other work
outside the call to runOMTATest.
Two comments in AnimationCommon.h refer to 'mFlushCount' which was presumably
the old name for mAnimationGeneration. Also, one comment says
nsCSSFrameConstructor tracks this. This patch adjusts the comments to refer
to mAnimationGeneration and RestyleManager.
(The reference to nsTransitionManager::UpdateAllThrottleStyles() is still valid
since there is useful documentation accompanying that method despite the fact
that the relevant code is mostly contained in AnimationCommon.h since bug
914847. Eventually we will unify the structures of transitions and
animations to the the point that we can replace the
IMPL_UPDATE_ALL_THROTTLED_STYLES_INTERNAL macro in AnimationCommon.h with an
actual method. At that point we can move the documentation accompanying
nsTransitionManager::UpdateAllThrottleStyles and its references to
AnimationCommon.)
We need a basic representation of animations from which we can derive subclasses
to represent specific cases such as transitions. For now we will retrofit
ElementAnimation for that purpose hence renaming it to StyleAnimation.
This patch removes the "using namespace mozilla::layers" line from
AnimationCommon.cpp since the unified build system concatenates several files
together before compiling making using declarations like this leak into other
files potentially creating ambiguities. Previously, when we were calling
ElementAnimation, 'Animation', there were ambiguities between
mozilla::layers::Animation and this new 'Animation' class. In general, it is
probably a good idea to limit the scope of these using declarations so I've kept
that change.
This patch relocates ElementAnimation from nsAnimationManager.{h,cpp} to
AnimationCommon.{h,cpp} and in the process moves it into the mozilla::css
namespace.
ElementAnimation::HasAnimationOfProperty doesn't seem to be overridden anywhere.
I suspect it was a copy-paste mistake because the methods of the same name on
ElementAnimations, ElementTransitions, and CommonElementAnimationData are
virtual.
Now that ElementTransitionProperty inherits from ElementAnimation,
ElementTransitions::HasAnimationOfProperty can re-use
ElementAnimation::HasAnimationOfProperty in its definition of
ElementTransitions::HasAnimationOfProperty.
Similarly, in nsDisplayList::AddAnimationsAndTransitionsToLayer we can use this
method rather than drilling down to the appropriate segment by hand.
Both ElementPropertyTransition and ElementAnimation specify an IsRunningAt
method which have the same purpose but with two subtle differences:
a) ElementPropertyTransition::IsRunningAt checks if the transition is a removed
sentinel and if so returns false. This patch adds a check for a null start time
to IsRunningAt since I think in future we will want to allow null times in
various places to represent, for example, animations that are not connected to
a timeline. (However, ultimately we will probably not allow start times on
*animations* to be null, only on their associated player.)
Should we later use a different mechanism for marking sentinel transitions (e.g.
a boolean flag) this method should still be correct as it checks if aTime is
inside the transition interval before returning true.
b) ElementPropertyTransition::IsRunningAt returns false if the transition is in
the delay phase, that is, waiting to start. This patch changes this behavior so
that transitions are considered running even if they are in the delay phase.
This brings their behavior into line with animations and removes the need for
the ElementPropertyTransition::mIsRunningOnCompositor since it is only used to
determine when a transition in the delay phase has begun.
ElementAnimation::IsRunningAt also handles pause state and iterations but this
logic should still be correct for transitions which, in this area, only use
a subset of the functionality of animations since their pause state is always
playing and their iteration count is 1.
As part of moving towards more shared data structures for animation, this patch
makes ElementPropertyTransition inherit from ElementAnimation. At the same time
we switch from storing the target property, start/end values, start time, delay,
and timing function on the transition to the corresponding location in
ElementAnimation.
Since nsDisplayList::AddAnimationsAndTransitionsToLayer was already doing this
conversion in order to create animations to pass to the compositor thread, we
can remove the conversion code from there and just use the ElementAnimation data
structures as-is.
A number of assertions are added to verify that transitions are set up as
expected (namely, they have only a single property-animation with a single
segment). As we move to more generic handling of animations and transitions
these assertions should disappear.
As a first step towards making CSS animations and CSS transitions use the same
data structures, this patch aligns their behavior with regards to start time and
delay handling.
Previously, ElementAnimation objects maintained separate mStartTime and mDelay
members whilst ElementPropertyTransition objects maintained a single mStartTime
property that incorporated the delay. This patch adds an mDelay member to
ElementPropertyTransition and stores the delay and start time separately.
Calculations involving ElementPropertyTransition::mStartTime are adjusted to
incorporate mDelay.
I confirmed that the crashtest crashes in the harness without the patch.
--HG--
rename : layout/reftests/backgrounds/blue-32x32.png => layout/style/crashtests/blue-32x32.png
This adds a check that is currently present in most but not all
codepaths leading to this point, but which patch 4 will remove from many
of those codepaths.
Had patch 3 not been present, this would be needed to prevent a test
failure with patch 4 (which removes the ExpectEndProperty check from the
CSS_PROPERTY_PARSE_VALUE case in
CSSParserImpl::ParseProperty(nsCSSProperty) since its callers handle
checking for appropriate endings), since the way this function returns
success for empty values leads var() functions alone inside
font-variant-alternates to be rejected, since
CSSParserImpl::ParseProperty(nsCSSProperty) won't try reparsing with
variables.
Values that are already in invalidGradientAndElementValues don't also
need to be listed in an array that has invalidGradientAndElementValues
appended to it.
* Refuse to serialize some combinations of values that the shorthand
can not represent: 'grid-template-areas: (not none)' combined with
'grid-template-rows: subgrid' or 'grid-template-columns: subgrid'.
(The former used to cause an assertion failure.)
* Remove an extraneous trailing space that occured when a <track-list>
was last. (ie. followed by an omitted <line-names>)
* Add tests for the result of this serialization.
This patch adds an extra check for paint suppression when waiting for paint
events. This is because on some platforms (notably B2G) we can think all paints
have completed because paint suppression is in effect and as a result call the
callback too soon.
This patch use window.setTimeout(..., 0) to wait for paint suppression to finish
before preceding to check for pending paint events.
When the refresh driver is under test control, if we detect that paint events
are pending we need to force a refresh driver tick. This patch adds that tick.
I suppose we had previously never hit this situation before and never noticed
this.
This patch also rearranges the main loop so that early returns appear first and
calling the callback appears at the end.
... and a bit of grid-auto-flow, for the grid shorthand.
* Avoid using CheckEndProperty() when possible
* Distinguish between "error" and "not a <track-size>"
* Split out parsing of a <track-list>, given its initial [<line-names>?]
When we have a backwards fill and we sample at *exactly* the start of the
animation on the next refresh driver tick, when we get to
RestyleManager::ComputeStyleChangeFor (or more specifically
ElementRestyler::CaptureChange) we notice that the style hasn't changed (since
the first frame of the animation produces the same value as the backwards fill)
and end up with an empty change list. As a result we never schedule a view
manager flush and rebuild the layer. Hence, the animation never gets sent to the
compositor thread. On the next tick we're already throttling the main thread.
This patch fixes this by applying the same approach as is used for transitions,
that is, explicitly marking which animations are running on the compositor
thread so we know if we need to trigger a layer transaction or not. This should
not only be more robust than the previous code but also facilitate aligning
animations and transitions code (bug 880596).
This test reproduces a bug where we don't send an animation to the compositor
thread. The important step is the sample precisely at the start of the animation
interval.
