We don't actually need to re-calculate if the updated properties are the
same as the old one. This change avoids problematic nested calls of
nsStyleSet::GetContext() in particular cases.
MozReview-Commit-ID: JksiTGX57Fy
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
Previously, when fetching an nsPresShell, we would look up the current realm
document and get the pres shell for it. This patch makes us call GetPresShell()
which uses GetRenderedDocument() which corresponds to the composed document of
the target effect which seems more consistent since it is the target effect we
will use as context for computing CSS values (as required by [1]).
[1] https://w3c.github.io/web-animations/#calculating-computed-keyframes
MozReview-Commit-ID: 9S55041rfTp
--HG--
extra : rebase_source : c52d4c366d0a2891958c8f7378614a8feb5e7c70
Note that when we actually compute values, we will use the composed document of
the target element (see the next patch in this series).
MozReview-Commit-ID: 8Pp3y19pltP
--HG--
extra : rebase_source : bb1c21f3fdcf2e831213d2f278d70e4ca2637028
There doesn't seem to be a need to have a separate 'sandbox' folder just for
this test. It's a Gecko-specific test so it can go in the 'mozilla' folder.
MozReview-Commit-ID: 340knfWtcD7
--HG--
rename : dom/animation/test/sandbox/test_set-easing.html => dom/animation/test/mozilla/test_set-easing.html
extra : rebase_source : 44a03425bbfee97a06d498224dcaa76b51c3b317
While resolving style context, the primary frame of the target element
has previous style context so if we don't pass the newly created nsStyleContext,
UpdateCascadeResults uses the previous style to get overridden properties, it
will result unexpected cascading results.
MozReview-Commit-ID: osqXQlP43X
--HG--
extra : rebase_source : 1b34f9245367c2613807156559f09f5f2943458c
To create a stacking context for animations on transform:none segment,
we need to set NS_FRAME_MAY_BE_TRANSFORMED. The fix is comming in part 2.
Note that in case of animations which has properties preventing running on
the compositor, e.g., width or height, corresponding layer is not created
at all, but even in such cases, we normally set valid change hint for such
animations in each tick, i.e. restyles in each tick. For example:
div.animate([{ opacity: 1, width: '100px' }, { opacity: 0, width: '200px' }], 1000);
This animation causes restyles in every ticks without this patch, this patch
does not affect such animations at all. The only animations which will be
affected by this patch are animations which has opacity/transform but
did not have those properies. e.g, setting transform by setKeyframes or
changing target element from other target which prevents running on the
compositor, etc.
MozReview-Commit-ID: 78fYqyX8uDX
--HG--
extra : rebase_source : c4a6ef244f26f3d808fd2c6a5f80c1a15478ae31
We already have a wrapper named nsIFrame::BackfaceIsHidden().
MozReview-Commit-ID: 5L49W6wtXs1
--HG--
extra : rebase_source : d3be8d028453e63fb2d3d96b5956262d352385ef
If there is a possibility that long duration property causes overflow on
TimeStamp calculations, we should use shorter duration in our tests.
MozReview-Commit-ID: HJThoX80W4Y
--HG--
extra : rebase_source : 8986afa9a58d832e15194b8ea9533af380a127a4
This implements the changes to the specified behavior from the following
changeset:
a9ba51338e
It also updates test expectations based on the tests updated in part 1 of this
patch series.
MozReview-Commit-ID: HyJC8tHXLYc
--HG--
extra : rebase_source : 6d0f5eb03a2bb4c3938d79dfae7ee433d33fd2b1
Handle these cases:
1. When creating null-target effect whose spacing mode is "paced":
- Fall back to distribute spacing. This case is already included by previous
patches.
2. When setting a target to null:
- Apply distribute spacing.
3. When style context is null.
- Fall back to distribute spacing.
4. When setting a new valid target:
- Use this new target as the context element and re-calculate the computed
offsets. This case is already included by previous patches.
MozReview-Commit-ID: 1zhSOAylnZb
--HG--
extra : rebase_source : e2988f433f395a398090dc08f262b0154de3dc50
Do a simple refactor, so we can reuse the getter of nsStyleContext.
MozReview-Commit-ID: 4BQ7f8HuFns
--HG--
extra : rebase_source : 37bbf6af795484c5d80d308683e4fcdfe23c7a1a
Calculate the paced spacing for each Keyframes by the context element. Use the
algorithm in the spec.
MozReview-Commit-ID: HFWQwoKhKWt
--HG--
extra : rebase_source : 40112eb1f722179cfc0a4ccbd188e22bc7af9b9b
We want to reuse the StyleAnimationValues of properties of each keyframe when
applying spacing and building animation property segments, so refactor this
part.
MozReview-Commit-ID: 8G56C3BU3FR
--HG--
extra : rebase_source : 73b6d374ac8bd25645d1b1b2f15f4e778b3ec949
When we apply paced spacing, we have to check if there are still null computed
offsets after applying paced spacing to paceable Keyframes because the
calculation of distance may be failed or some Keyframes are not paceable in
the specific range. Therefore, using -1 would be easier to check it.
Also, add a const, kComputedOffsetNotSet, to represent this invalid value.
MozReview-Commit-ID: GPhj7cdiX2W
--HG--
extra : rebase_source : 8c4e7769c454fe50eb1cc08db63866dcc4ed62e5
Rename it to ApplySpacing, and let it handle both distribute and paced mode.
MozReview-Commit-ID: 2kGA6LMHUsz
--HG--
extra : rebase_source : ebd5566392b1ea6a4a445ff7c3ed81cdc94bdded
We only support spacing mode from Web Animations API, so add a simple parser and
use it only from the API. In this patch, parse spacing mode from the constructor
and throw TypeError if we have any parse error.
MozReview-Commit-ID: 9H7g80IcZfZ
--HG--
extra : rebase_source : e1bc781ff0f20a1a38c04e672832ec013edc549d
Add a new file, KeyframeEffectParams.h, and define the basic data
members nsString for the spacing mode.
Also, add one more argument, const KeyframeEffectParams&, to the
constructors of KeyframeEffect(ReadOnly).
MozReview-Commit-ID: I7LYlnv6LLb
--HG--
extra : rebase_source : 9aebb7b9659588674c2a954eb2ce62c827bc9830
Before this patch, we could't use EffectSet::GetEffectSet(nsIFrame*) until
the target content associated with the nsIFrame has a primary frame since
nsLayoutUtils::GetStyleFrame(nsIContent*) needs the primary frame.
In this patch, StyleContext()->GetPseudoType() is used for obtaining
CSSPseudoElementType instread of content->NodeInfo()->NameAtom().
As a result, we don't need to care about whether the content has a
primary frame or not.
If we run following code, content process will crash.
------
anim1.timeline = timeline;
anim2.timeline = document.timeline;
anim2.timeline = timeline;
------
The AnimationTimeline has LinkedList variant. (called mAnimationOrder) And Animation is sub-class of LinkedListElement.
We will create the relationship of AnimationTimeline and Animation when calling the AnimationTimeline::NotifyAnimationUpdated. However we didn't remove these relation ship when setting new timeline.
So we should remove these relationship when setting new timeline object.
MozReview-Commit-ID: RDyranduTA
--HG--
extra : rebase_source : 1f080ad80f258162e94f80470a7464e2a9bb033b
This is implementation of 'Setting the timeline of an animation'.[1]
[1] https://w3c.github.io/web-animations/#setting-the-timeline
MozReview-Commit-ID: A5YMXhkxHjr
--HG--
extra : rebase_source : 73e4fdc9ee98bf756267a05a2336a2c51517cf34
In order to raise an assertion in CanIgnoreIfNotVisible() which will be
introduced in part 3 when the cumulative hint is not properly, we should skip
the calculation when mProperties is empty.
BuildSegmentsFromValueEntries now needs base nsStyleContext to calculate
the change hints.
If the change hint is not set correctly, we will check it in
CanIgnoreIfNotVisible() introduced in a subsequent patch (part 3).
* Some tests in gAnimationsTests are moved to gAnimationWithGeometricKeyframeTests.
* `expected.withoutGeometric` represents expected values where 'width' is *not* applied.
* `expected.withGeometric` represents exptected values where 'width' is applied.
MozReview-Commit-ID: 6PJttztMGxI
--HG--
extra : amend_source : 5592317764ff5a9a3db44e7be9073ff426370224
I modified several tests which related animationstart event delay.
animation-starttime and animation-currenttime tests:
- Moved the getComputedStyle tests to test/style.
- Removed the animation.playState tests. This tests contained by playState tests of web-platform-tests.
- Lining common function. (e.g. calculating current/start time. etc)
MozReview-Commit-ID: 9kD9ZR1KxGv
--HG--
extra : rebase_source : 26e37568769fd4e939ebbde36d8b4af5ad4d2658
This patch also includes a tweak to not-animatable.html to match the order in
which properties are enumerated on the object. This test was always in error but
we never noticed since the test failed before reaching the test in question.
Making the test dependent on the order in which object properties is enumerated
is not good but we will remove this test in the next patch. In this patch we
just make sure it passes.
MozReview-Commit-ID: AKXdHj4nUMv
--HG--
extra : rebase_source : 64270ae9d9cf68cdf534baaf198583fb1974025c
In order to support CSS variable references in animation properties we need to
handle token stream values. However, we already use token stream values for two
other purposes:
* To store shorthand property values
* To store invalid longhand property values
The shorthand property value case is already handled correctly, however for
longhand values we need to distinguish between valid token streams (e.g.
values that contain variable references) and invalid values stored as token
streams.
This patch makes us do that by looking at the mPropertyID member of the
nsCSSValueTokenStream object which will be eCSSProperty_UNKNOWN for an invalid
value but will be set to something sensible for a valid token stream.
MozReview-Commit-ID: AXUaO5dopBC
Rather than defining the same type redundantly but with a name that overlaps
with a struct in KeyframeEffect.h (that has a different type).
MozReview-Commit-ID: 3MbvXWL8XlL
The test case here does not check whether requesting restyles for empty
properties are skipped or not. It just checks that whether restyles happen or
not because there is no way to check each request for restyles yet.
MozReview-Commit-ID: I5XMYfCTYU8
--HG--
extra : rebase_source : 893aaaf2c47e05f37bce9913df4f14e3021f215a
There were two places run gAnimationsTests in
test_animation_performance_warning.html.
MozReview-Commit-ID: zrD5eMiDsy
--HG--
extra : rebase_source : 250f826daed4440725c0a28fdb1fcd84fd299402
This function will be used for the warning of small content as well.
MozReview-Commit-ID: EiUF9CgWGDA
--HG--
extra : rebase_source : 3b6daa713d889f5c51507d4c1f6fd6c51f1e7fb9
We will need to request a restyle and unregister the current target in
SetTarget(), and there are many duplicate code segments for them now, so wrap
them for reusing the code.
MozReview-Commit-ID: 33XoNspZme3
--HG--
extra : rebase_source : 881aa13d79ccc75872a6cc48d0a1da71cfdff2ae
Use ConvertTarget() to convert Nullabe<ElementOrCSSPseudoElement> into
Maybe<OwningAnimationTarget>, so SetTarget() can use it as well. The return type
of ConvertTarget is not Maybe<NonOwningAnimationTarget> because we need to
compare the return type with KeyframeEffectReadOnly::mTarget, so using the same
type would be easier to implement.
MozReview-Commit-ID: GskbydOMoo0
--HG--
extra : rebase_source : d1a8fe2d8fe89e4ffdb79844ab5581a9af3b2ce5
1. Define OwningAnimationTarget.
2. Replace the KeyframeEffectReadOnly::mTarget/mPseudoType members with
a Maybe<OwningAnimationTarget> mTarget member.
MozReview-Commit-ID: 65qOoNyDRSy
--HG--
extra : rebase_source : b938dbc00c918861d4141128fad8e30f61668e40
We set a null target only from Web Animations API, so make sure
KeyframeEffectReadOnly::ConstructKeyframeEffect() can handle null target
properly.
MozReview-Commit-ID: D6PoV7PGFj3
--HG--
extra : rebase_source : 4ba2d616d6b2cdfe7985ced29e4454e818d076b8
We don't need to restyle if mTarget is nullptr, so skip it. For
nsAutoAnimationMutationBatch, we also skip it if mTarget is nullptr.
AnimationColletion, nsAnimationManager and nsTransitionManger are for
CSS Animations and CSS Transtions, so the effect should have an effective
target. Therefore, I think we don't have to revise them for
nsAutoAnimationMutationBatch.
MozReview-Commit-ID: Egzr1QVEa0v
--HG--
extra : rebase_source : 2f9125f71f67a3d50f2126fed4d1b459d938de22
Currently isRunningOnCompositor flag is not cleared when 'display:none'
is set to the target element.
We need to fix it at some point.
MozReview-Commit-ID: CjtWUyT9CP9
--HG--
extra : rebase_source : c1da5ed5e79f9a7f78d920943dabad719cb7abc7
WebIDL referes to KeyframeEffect::SetFrames(), which is derived from
KeyframeEffectReadOnly::SetFrames() in terms of implementation.
In addition, make KeyframeEffectReadOnly::ConstructKeyframeEffect call
KeyframeEffectReadOnly::SetFrames() to simplify the code.
MozReview-Commit-ID: 7ASbtoN7Tnp
--HG--
extra : rebase_source : c398ff7154c4533255f56c7ca13314e440eb6258
Add KeyframeEffectReadOnly::mTiming into the list of cycle collection to
avoid any possible memory leak.
MozReview-Commit-ID: C5mFQ7TsqC7
--HG--
extra : rebase_source : 8ee1e58d69a3becb0b8566fa3529154bb66d3064
Use the current document as the parent object of
AnimationEffectTiming(ReadOnly).
MozReview-Commit-ID: JfPLk95hsJ1
--HG--
extra : rebase_source : ee068d0eb8e26f4c1e83b87049be8060fcd27813
It turns out that std::stable_sort on Mac and Android use this.
Bug 1263500 tracks doing something more efficient on those platforms.
MozReview-Commit-ID: 3tGbnoW67QP
This is needed in order to use std::stable_sort with this type since some
implementations of std::stable_sort require this (as opposed to simply a move
constructor).
MozReview-Commit-ID: 5QmcIxkC4aB
Before switching CSS animations over to using KeyframeEffectReadOnly::SetFrames
we update the getFrames() API to return the set frame objects (when available)
so that we can test that we are setting the correct frames.
MozReview-Commit-ID: 4SpBRM7Ykyv
Earlier in this patch series we divided keyframe processing into two stages:
(1) Turning javascript objects into an array of Keyframe objects
(2) Calculating AnimationProperty arrays from the Keyframe objects
This patch creates a SetFrames method so that CSS animations and
CSS transitions can skip (1) and pass the frames constructed from CSS syntax
into (2).
It also adds the following additional processing:
a. Notifying animation mutation observers when the set of frames has changed.
This is currently performed by nsAnimationManager but ultimately we should
encapsulate this logic inside the effect itself. Furthermore, it will be
needed when we implement effect.setFrames() (i.e. the Javascript-facing
wrapper for this method).
b. Preserving the mWinsInCascade and mIsRunningOnCompositor state on properties
when updating them.
This is currently performed by:
bool KeyframeEffectReadOnly::UpdateProperties(
const InfallibleTArray<AnimationProperty>& aProperties)
which is what nsAnimationManager currently uses. We will ultimately remove
the above method and here we are just moving this code to the new version
of UpdateProperties.
c. Requesting a restyle when the set of AnimationProperty objects has changed.
Again, this is currently performed by the existing UpdateProperties method
so we are just moving it here. This behavior will also be required when
we implement effect.setFrames() and when we call UpdateProperties from
elsewhere in restyling code.
This is bug 1235002 but we fix it here and leave that bug to just do further
cleanup work (e.g. re-instating the check for an empty property set before
requesting a restyle in NotifyAnimationTimingUpdated).
d. Marking the cascade as needing an update when the set of AnimationProperty
objects has changed.
This is in preparation for calling UpdateProperties from elsewhere in
restyling (e.g. when the nsStyleContext is updated).
MozReview-Commit-ID: 2ll26lsWZTm
In KeyframeEffectReadOnly::ComposeStyle we call StyleAnimationValue::Interpolate
but assume that it always passes. That was true when that code was only used for
CSS animations and CSS transitions since they check that their animation values
can be interpolated before setting up segments.
However, when we set up animations using the Web Animations API we don't perform
that check so it is possible for this call to fail.
In that case, we could just bail, but, according to CSS Transitions we should
apply a 50% switch in this case:
https://drafts.csswg.org/css-transitions/#step-types
(In Web Animations, specifying this is an open issue. See:
https://w3c.github.io/web-animations/#specific-animation-behaviors).
Bug 1064937 tracks doing this in general (we'll likely need to mark various
properties as being no longer unanimatable but instead as supporting discrete
animation) but we can start to introduce it now.
Later in bug 1245748, CSS animations and transitions will likely start using
the same code path as the Web Animations API for setting up keyframes.
As a result, unless we take care to add checks that the values we set are
interpolable, the 50% switch behavior will begin to apply to CSS animations and
transitions too at that point.
Some concerns have been raised about possible web compatibility issues around
the 50% switch behavior (see [1] and [2]). For CSS animations, Chrome already
supports this behavior so it should be ok at least for CSS animations.
When we switch CSS transitions over to the same code path, however, we will need
to be careful to add checks that the transition endpoints are interpolable
(we can investigate introducing this behavior to transitions as a separate bug
that can be easily backed out / preffed off).
Regarding the naming of the test added here, going forward we would like to
restructure the tests under web-platform-tests to better match the structure of
the Web Animations since that seems to be the convention there.
However, this doesn't *quite* match the structure of the spec since there are
upcoming changes to the spec in this area (e.g. renaming animation behaviors to
animation types). However, it should be close enough that we don't have to move
it around too much in future.
[1] https://drafts.csswg.org/css-transitions/#step-types
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1064937#c0
MozReview-Commit-ID: KcxILrckJg9
In the next patch in this series, we would like to update the error handling of
the call to StyleAnimationValue::Interpolate in
KeyframeEffectReadOnly::ComposeStyle. Using AnimValuesStyleRule::AddEmptyValue
there, however, makes handling the error case difficult because we need a means
of clearing the allocated StyleAnimationValue.
However, simply using AnimationValuesStyleRule::AddValue means we will end up
doing needless allocations for StyleAnimationValue objects (the copy
constructor for which can result in performing potentially expensive heap
allocations, such as when lists are deep-copied).
Instead, we add a Move constructor to StyleAnimationValue and add an overload
of AnimValuesStyleRule::AddValue that takes an rvalue reference. This
provides a more consistent interface to AnimValuesStyleRule and avoids the
unnecessary allocations from copying StyleAnimationValue objects.
MozReview-Commit-ID: CaP1uPAgNnm
In promise chains, we don't have to use t.step_func. However, when there
are callbacks in promise chains, assertions in the callbacks need wrapped
in either t.step or t.step_func.
If we use t.step_func, a variable scope might be divided. This can be a
problem when an assertion uses local-scope variable (e.g. the callback
in MutationObserver uses an assertion which take `changedAnimation`).
Therefore, t.step is helpful in this case.
(There no t.step_func we should remove in web-platform tests.)
MozReview-Commit-ID: IiSizgCQjpG
--HG--
extra : rebase_source : bfe314c20763d0ea26127dd561c64388d6431bf3
Previously, every test and support file would be synced to the objdir
when running any test. Now that only those support files and tests requested
are synced, we note support files required beyond those in a test's
directory in ini manifests.
MozReview-Commit-ID: EmlDz9d4lqt
In some of these cases, this increase isn't strictly necessary, because we only
check state immediately after creating the animation, before it could have
completed (regardless of its duration). Still: we should consistently use long
durations for any animations that aren't expected to complete during the test
run, because short durations might accidentally get copypasted into new tests
where they might cause intermittent failures.
MozReview-Commit-ID: 8wSRqHMI12L
--HG--
extra : rebase_source : 12e6a054dce047351b06e064bcedd9cdec58150f
I have confirmed that by adding this, we end up calling SwapElements() on the
mPropertyValues member when we build up the nsTArray<Keyframe> result in
GetKeyframeListFromPropertyIndexedKeyframe. Without this explicit move
constructor (i.e. with only the default move constructor) the copy-constructor
for mPropertyValues is called.
MozReview-Commit-ID: 6IWkP97RFUr
--HG--
extra : rebase_source : 4ac4b6545337810a3047f2cfb1dac86074116cfb
StyleAnimationValue::ComputeValue(s) will automatically look up the style
context of the supplied element. This is mostly fine, but when we start using
this method in scenarios where we are building the initial style context
(as happens later in this patch series) it can easily land us in a situation
where we iterate indefinitely.
It would be better, instead, to just explicitly pass in the style context we
want to use, as we already do for StyleAnimationValue::ExtractComputedValue.
MozReview-Commit-ID: ZoVBlBRRBI
--HG--
extra : rebase_source : 9012cc2e405fc887f070fbfaa2f9853289882862
Once we tweak moz.build in the next patch, the grouping in the unified build
will change and expose these missing includes so we fix them here, first.
MozReview-Commit-ID: GebEEociwTo
--HG--
extra : rebase_source : 18158fdf8a3c1a1dcf446118371cad1a15fd4daf
Specifically, for the 'composite' member on keyframes, we now indicate "use the
composite value specified on the effect" using a missing/undefined 'composite'
member as opposed to a null value.
MozReview-Commit-ID: ZH45GvCTlP
--HG--
extra : rebase_source : 5acf081fb844f81280765a87ec019b7847ca1885
Before we begin re-arranging KeyframeEffect.h we move ComputedTiming aside
since putting it in a separate file should make navigating the source
easier.
MozReview-Commit-ID: L5GTFAo00sh
--HG--
extra : rebase_source : e88b6ea092c459afa90831de8469697454e00c5a
Add tests in test_animation_observers.html, so we can test elements and pseudo
elements together by setting subtree.
--HG--
extra : rebase_source : 1841d5db93657a07772bc73ce99cb6ab2a43a737
We use the parent element of a pseudo element as the subject to be notified.
Usage:
We record animations targeting to pseudo elements by setting subtree attribute
to true.
MutationObserver(Node, { subtree: ture });
So all the animations targeting to the pseudo elements whose parentElement is
the first argument will be recorded.
--HG--
extra : rebase_source : 3dc87802b65c74c3e5f2ed4504652ba14465fc02
Use NonOwningAnimationTarget as the returned type of
1. KeyframeEffectReadOnly::GetTarget()
2. nsNodeUtils::GetTargetForAnimation(...)
--HG--
extra : rebase_source : 3b0e117528035329fdf4bdbee127f095b710805a
NonOwningAnimationTarget is a struct made of two members:
1. mozilla::dom::Element*
2. mozilla::CSSPseudoElementType
--HG--
extra : rebase_source : df7ecf192c14f1973b064ffe8a31618df2e6955d
At the same time we also make the 'warning' member of AnimationPropertyDetails
no longer nullable and simply use the absence of the member to indicate "no
warning" (which is what we were already doing -- we were never actually setting
it to null).
MozReview-Commit-ID: HdRDbqhCdmw
--HG--
extra : rebase_source : 0282bd9f0e213aa0e1ed1f5b25d58b10fb3dbc0b
extra : histedit_source : 7d1f81dc57e2a55ab0ed6c4919a25b87819d9d58
I think the reason we originally didn't do this is that the
"isRunningOnCompositor" status might be misleading for animations that are
being overridden. That is, there are some animations we don't send to the
compositor because they are being overridden by another animation (e.g. a
CSS animation touching the 'transform' animation will cause a CSS transition
on the same property not to run, despite the fact that transitions apply
higher in the cascade). This is not merely a performance optimization but means
we don't have to do the cascade on the compositor.
In the future, once we introduce additive animation, we won't be able to handle
this so simply since it an animation will be able to be partially overridden.
Instead, consumers of this API will need to look at the 'composite' member of
the various animation values to see if an animation is being fully or partially
overridden.
As a result, this API really should return all running animations, even if they
are currently being overridden.
MozReview-Commit-ID: DwmbXdCqF32
--HG--
extra : rebase_source : 14e5412015b6c2c7ec6b7e105d414a89fc746c77
We are now extending this API to include more than just metadata about each
animated property but also the property values themselves.
Note that we can't use the name AnimationProperty for the dictionary since
we already use that name internally and [BinaryName] doesn't seem to apply to
dictionaries.
MozReview-Commit-ID: AcXeN4fsgTz
--HG--
extra : rebase_source : 714fdf85484775244daad6aaa288b1ec73ad6793
This better matches the order in the WebIDL and, once we rename
GetPropertyState to GetProperties it will make sense for GetFrames and
GetProperties to be side-by-side.
MozReview-Commit-ID: 67s9WGksPFv
--HG--
extra : rebase_source : f38ea60c0fec2f063126a0aa73422230189afbf5
Later in this patch series when we convert tests from web-platform tests to
mochitest-chrome tests, some of the test cases that use zero-length segments
(overlapping keyframes at certain offsets) would trigger failed assertions
in KeyframeEffectReadOnly::ComposeStyle. This is because this method was
originally written with CSS animations in mind where segments cannot be
zero-length. Furthermore, when these same tests cases are run as
web-platform-tests, the failed assertions are not visible.
This patch adjusts the handling of segments to allow zero-length segments and
adds a test to check that the handling matches that defined in Web Animations
which is summarized in the following informative note,
"this procedure permits overlapping keyframes. The behavior is that at the
point of overlap the output value jumps to the value of the last defined
keyframe at that offset. For overlapping frames at 0 or 1, the output value
for iteration progress values less than 0 or greater than or equal to 1 is the
value of the first keyframe or the last keyframe in keyframes
respectively."[1]
[1] https://w3c.github.io/web-animations/#the-effect-value-of-a-keyframe-animation-effect
MozReview-Commit-ID: JdyYbGZtbot
--HG--
extra : rebase_source : 00502ec8aec423196376e29bf4b70ef0ff178e29
The type name has been changed and re-ordered.
MozReview-Commit-ID: 78jrJ6a9Pro
--HG--
extra : rebase_source : f47e6bf27d8e48d10b3af123308c2ab89e71d8e1
As well as generally simplifying the different KeyframeEffect(ReadOnly)
constructor methods, this patch also means we will use the realm document for
parsing timing functions in all cases. Although this currently doesn't have
any impact (the current set of timing functions are expected to be parsed
identically regardless of the document used) it may become significant if, in
future, it becomes possible to register hooks with certain documents for
parsing CSS properties as part of the houdini efforts.
MozReview-Commit-ID: 4gAZi1G1uAD
--HG--
extra : rebase_source : f619592a02ddcbe56835344ec1fb3023219cd2d3
Once we update TimingParams to take a document, we will need to get an
appropriate document within the various constructor methods. This complicates
these methods and suggests they should be pushed into the .cpp file where
we can hide the complexity more easily and templatize the type of the options
argument so that we can share the document-fetching code.
By moving all uses of the declared template methods to the .cpp file we
can drop the explicit instantiations.
(We still need to declare the templated methods in the header file since
these methods need to be protected methods of KeyframeEffectReadOnly in
order to construct a KeyframeEffectReadOnly since its constructor is
protected.)
MozReview-Commit-ID: 8KrCWrWIb7X
--HG--
extra : rebase_source : c5b550b271cc68ceeb60a25243268a17b3ab7f65
Adds a utility function for getting the document on the global associated with
a JSContext. We will need this in various situations where we want to use
the CSS parser (which requires various bits of state we pull off a document)
to parse a timing function but might not have a target element.
Strictly speaking we currently always have a target element but in future we
expect to support creating KeyframeEffects without an associated target
element. Also, we will need this for some situations in bug 1245748 where we
need to parse CSS properties on keyframe objects when we may not have a
target element.
MozReview-Commit-ID: Klku1LFoRGp
--HG--
extra : rebase_source : f2aa06aafb8fa9b212791a3e602a168f5170fcd9
Each warning message is generated only when getPropertyState() is called.
MozReview-Commit-ID: C03ZSvPv9ff
--HG--
extra : rebase_source : 5932957f8f0b171c7b100b1c22e70513959c819e
Those message will be modified in part 4 (localization).
MozReview-Commit-ID: 6TMUxemVLcu
--HG--
extra : rebase_source : 65ef1879b3e606ae6dc279981b1e995c7b2cd40b
In order to convert CSSPseudoElementType into its underlying type easier,
we define CSSPseudoElementTypeBase. However, keep using uint8_t directly for
forward declarations.
Now we produce computed timing progress outside [0,1] range.
We use the last segment to calculate animation values if the value is greater than 1.
We use the first segment to calculate animation values if the value is lesser than 0.
Currently endTime is calculated when getComputedTiming() is called. As a
result, the value returned there doesn't necessarily reflect what we are using
in the model. It would be more simple, consistent and useful if we simply
calculate this as part of GetComputedTimingAt and use it both internally and in
the result to getComputedTiming().
With the added tests in part 4 we crash without this change because we end up
trying to multiply an infinite iteration duration by a zero iteration count
which trips an assertion in StickyTimeDuration. Hence we fix this behavior
before adding the tests.
Implement GetTarget() and functions of CSSPseudoElement.
We use a strong reference from CSSPseudoElement to Element and a non-owning
reference from Element to CSSPseudoElement.
This means that we won't associate animations with additional frames.
In this case, this fixes associating off-main-thread animations with a
table outer frame, when they should have been associated only with the
table frame.
Locally, the test fails without the patch (with opacity in the test
being 0.36 instead of the expected 0.6), and passes with the patch.
(Opacity 0.36 gives a color of rgb(163,163,255), whereas 0.6 gives
rgb(102,102,255).)
--HG--
extra : commitid : 7wtkIDLDHBF
We don't need observe restylings other than animations. If those restylings
happen, it's just noise for this test. We should drop them.
--HG--
extra : transplant_source : 9%0B%0B%B7O%E5R%86%D4%7F%29%90q%DDQ0%0B%FAuJ
Before this fix, sometimes an element which was removed in a prior test
would still visible when subsequent test starts.
We should wait for paints to complete after the element has been removed.
--HG--
extra : transplant_source : %C7%7F%03%0F%DA%05A%C1%CE%F0m%DA1%C5%1D%FA%06%FA%FE%CA
Nothing() represents linear function, i.e. skip calculation.
ParseEasing is changed to return a Maybe<ComputedTimingFunction>,
if timing function is linear function, ParseEasing returns Nothing().
This is also for compositor side.
we need a new class to share the function which converts TimingFunction
to ComputedTimingFunction for either keyframe's timing function or keyframe
effect's timing function.
This will allow us to re-use the constructor from Animatable.animate() since the
existing type, UnrestrictedDoubleOrKeyframeEffectOptions, is not compatible with
UnrestrictedDoubleOrKeyframeAnimationOptions (introduced in the next patch in
this series), as used by Animatable.animate()
In current our implemantation, animations which can run on compositor
in invisible element can not run on compositor on all desktop platforms.
*BUT* both on Android and B2G the animations still run on compositor somehow.
And one more thing. Animations can run on compositor in elements which are
scrolled out in the parent element *RUN* on compositor as well.
mochitest does not allow us to disable each test on specific platforms respectively.
One we have mozinfo in mochitest (bug 1150818), we can skip the tests on specific platforms.