In the next patch, we are going to unthrottle UpdateOverflow change hint which
is also produced by non-transform properties.
MozReview-Commit-ID: BrJxo32uBJO
--HG--
extra : rebase_source : daeb91bc4ce44a120ce4092f9f113c78f0553326
In the next patch, we are going to unthrottle UpdateOverflow change hint which
is also produced by non-transform properties.
MozReview-Commit-ID: BrJxo32uBJO
--HG--
extra : rebase_source : daeb91bc4ce44a120ce4092f9f113c78f0553326
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
Without this fix layout/reftests/css-animations/ib-split-sibling-opacity.html
would have failed if the next change in this patch series is applied.
MozReview-Commit-ID: CFNXePkXuOs
--HG--
extra : rebase_source : 48df6bf107e1a14dd2b2ae7c23d38d29581aabcb
By doing this we will have all the KeyframeEffect* related code in
KeyframeEffectReadOnly.{h,cpp} so we can rename them to KeyframeEffect.{h,cpp}
in the next patch and make it easier to examine the history for the bulk of this
code.
The added [HeaderFile] annotation will be removed in a subsequent patch in this
series.
MozReview-Commit-ID: Fxk6fPukgAS
--HG--
extra : rebase_source : 0bb0f846aba69e2b79724adb3148948317667eae
This might seem a bit odd but later in this patch series we will rename
KeyframeEffectReadOnly to KeyframeEffect.
MozReview-Commit-ID: H9b8brtA36W
--HG--
extra : rebase_source : 9e34d583c087733b3fa05d99a67def55653c4556
It might seem a bit odd to move the setters to the read-only class that we are
ultimately planning to drop but the reason for doing this is that
KeyframeEffectReadOnly.cpp has a *lot* more code than KeyframeEffect.cpp.
In order to simplify code archaeology we take the following approach:
1. Move code from KeyframeEffect.{h,cpp} to KeyframeEffectReadOnly.{h,cpp}.
2. Delete KeyframeEffect.{h,cpp}.
3. Rename KeyframeEffectReadOnly.{h,cpp} to KeyframeEffect.{h,cpp}.
Note that at least steps 2 and 3 must be performed in separate patches as
mercurial does not successfully track renames when the target name already
exists.
MozReview-Commit-ID: LwJoxGJitKR
--HG--
extra : rebase_source : ae437c6e74435b983c7390df301055472fa3c4ff
The difference between nsDocument::IsWebAnimationsEnabled and
nsContentUtils::AnimationsAPICoreEnabled is that the former checks the caller
type and treats the preference as set for system callers which is particularly
needed for enabling things like the getProperties() API for DevTools etc.
Generally in API-facing call sites we have a JS context / CallerType and so we
want to distinguish between system callers and non-system callers. However, for
a few internal uses--specifically filling-in missing keyframes--we don't care
about the caller type and always follow the pref setting.
That may or not be quite what we want, but this patch doesn't change that except
for one call site: KeyframeUtils::GetKeyframesFromObject. This patch changes
GetKeyframesFromObject from *not* checking the caller type to checking the
caller type. That seems to be the correct behavior here since this is called
from KeyframeEffectReadOnly::SetKeyframes(JSContext*, JS::Handle<JSObject*>,
ErrorResult&) (i.e. a JS API-facing call site) where we *should* enable the full
API when the caller is chrome code.
MozReview-Commit-ID: FQJBk3zytwd
--HG--
extra : rebase_source : 577bca1e551e39fecfab309f64c993eba110337f
The telemetry is recorded once per effect:target pair, and is intended for
comparison with the telemetry added in bug 1349808.
MozReview-Commit-ID: 8JYbAifjmki
--HG--
extra : rebase_source : a5adf4ea9c0836d9ad0ecde5e5869d00eccc2205
The telemetry is recorded once per effect:target pair, and is intended for
comparison with the telemetry added in bug 1349808.
MozReview-Commit-ID: 8JYbAifjmki
--HG--
extra : rebase_source : fa0b615684ca1355f9bbc24b3355e90001db47b5
Use [SetterThrows] for KeyframeEffect.spacing because it throws if the input
string is not conformed to the grammar.
MozReview-Commit-ID: CkAnPu8TnV
--HG--
extra : rebase_source : af0960391684323a25ac0b40da28dcbe5c3c2919
I came across these while working on a different bug that changed the grouping
in the unified build. Adding these as a separate step will hopefully remove a
little noise from the next patch in the series.
MozReview-Commit-ID: Km7wTcVWG9n
--HG--
extra : rebase_source : 0610add67482c1a5aa7c4f576e151ed9437698c0
After updating a new animation, I think we don't need to request a restyle for
the new animation because:
1. CSS Animation & CSS Transition: we don't need to request a restyle.
2. Animation constructor: we don't need to request a restyle.
2. Animation.effect: we call PostUpdate() after SetEffectNoUpdate() already.
MozReview-Commit-ID: HrUGBrbt7xi
--HG--
extra : rebase_source : 0c2574be26bade3b17a31da361d24333f6409689
We mark the cascade update many times, so it's better to factor it out.
MozReview-Commit-ID: HbE980gOJ9M
--HG--
extra : rebase_source : a76dfc489f378c5bd7e711f296d0599ecf2322c5
