The implementation of the template function is defined in KeyframeUtils.cpp,
whereas the caller is inside KeyframeEffectReadOnly.cpp. I guess it's been
compiled accidentally because of unified builds.
MozReview-Commit-ID: 9GeIT7nDpLG
--HG--
extra : rebase_source : ce58ac6a013ff45d402c51994eb4f0bc28a2c671
This patch reflects the following change to the Web Animations spec:
abf76745b5
MozReview-Commit-ID: A2GD1igUf5f
--HG--
extra : rebase_source : 8129f6386b144adebc3bf0320ca7d6bfbba7a2e9
We have ServoCSSParser class, and I think it's better to move those
Servo FFI into this class to avoid including ServoBindings.h everywhere.
MozReview-Commit-ID: 6orXtddp9ZU
--HG--
extra : rebase_source : 6da4158c4fec606aaee49fddee3192f94d6c85a3
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
This was automatically generated by the script modeline.py.
MozReview-Commit-ID: BgulzkGteAL
--HG--
extra : rebase_source : a4b9d16a4c06c4e85d7d85f485221b1e4ebdfede
There are no reliable steps to make this happen but it appears to have happened
at least twice during fuzzing. As a result, it doesn't matter too much what the
behavior here is as long as we don't crash.
MozReview-Commit-ID: 4gdiBL2wngU
--HG--
extra : rebase_source : 54afce721f8b59c2ad038e0c2222f64e71a9b917
This implements the changes specified in these three spec changesets:
8efd180bd9f43ecdfbe5a4f1ad1a60
MozReview-Commit-ID: KFhgZ5ip6BA
--HG--
extra : rebase_source : aa18f8e3fbcd5d96194ff9a5239a3c415622dc2f
As required by the recent spec change:
d696468777
MozReview-Commit-ID: Ev6kUk1uLAY
--HG--
extra : rebase_source : 70f8ca3143a8b3bb4e03016b9989925d5a328049
There is no spacing mode any more, so rename this function.
MozReview-Commit-ID: 9DIqKmQnuJo
--HG--
extra : rebase_source : 3600be87a699a1a5fe237f8ed75baf03f0b5ae84
When styling with the Servo backend, we should also use the Servo backend to
determine if a property is animatable or not. However, if we do this,
Servo_Property_IsAnimatable will start returning true for the 'display' property
once we mark that as animatable in Servo (for SMIL).
Even if we later fail to actually animate 'display' (due checks added to Servo
in the next patch) we still need to treat 'display' as un-animatable in
KeyframeUtils so that we don't *read* the 'display' property of Keyframe objects
passed to the Animations API, since that is observable.
This patch makes us consult Servo_Property_IsAnimatable when using the Servo
backend and also explicitly treat the 'display' property as not animatable.
MozReview-Commit-ID: 1JllbeJisAS
--HG--
extra : rebase_source : d73b7d9ee0da03bfed68e574b67e10b342c1868d
In subsequent patches, the servo version of KeyframeUtils::ApplySpacing()
changes fifth argument to const ServoComputedValues*. If we still use nullptr
for the fifth argument in caller side, compilers can't determine whether
nsStyleContext* or const ServoComputedValues* should be used.
MozReview-Commit-ID: 1bE2cA7gRdi
--HG--
extra : rebase_source : 230b9b94bbfdcacf1b35a6c8eb1186e22b331047
I've propagated quirks mode information on some places. But we needed to pass
quirks mode to some other FFI functions to be able to handle that information
properly.
MozReview-Commit-ID: JovQWjN3YJx
--HG--
extra : rebase_source : bd25ba4276ae21ff4feb80e56b311202019268a0
We need another flag that represents allow-negative-number for SMIL, so
this enum will also comprise the another parsing mode that allows negative number.
MozReview-Commit-ID: IDFNppjGeB
--HG--
extra : rebase_source : 456f661b33346ff4a756a66c6accf4ab1a5f2f80
We can reuse ParseProperty in nsDOMWindowUtils::ComputeAnimationDistance(),
so factor out this function.
MozReview-Commit-ID: FdXGPxOZf84
--HG--
extra : rebase_source : 525bb436fdc1ce4d1241a08b198f9cd572506a86
We will use this type later in this patch series in nsSMILCSSProperty so this
patch moves it to a separate file so it can be re-used.
MozReview-Commit-ID: 4Z7YbsQ9xz4
--HG--
extra : rebase_source : 0f6f7248d1a4dfc77360829f3a0e6ed263f156db
This patch does the following in addition to a simple move:
* change the type of the pointers from RefPtr to nsCOMPtr
* move it from mozilla::css namespace to mozilla
MozReview-Commit-ID: 72MYq6kWm4s
--HG--
extra : rebase_source : 400fe0d7cc422f22592c302cfd4e457830b77e3e
Otherwise we hit below assertion in nsCSSValue::DoReset().
MOZ_ASSERT(NS_IsInCompositorThread() || !ServoStyleSet::IsInServoTraversal());
PropertyValuePair.mValue was introduced for computing paced timing in the case
where there is some invalid values in keyframes. Paced timing has been removed
removed from the spec and stylo will not support paced timing. So we don't need
to set the value for stylo.
MozReview-Commit-ID: 3I8QSvF2jL8
--HG--
extra : rebase_source : 42155d7fac85aa7fb068e8a514867e8f1c27ed30
While we're here, don't re-recompute the default computed values, just grab them
from the device.
MozReview-Commit-ID: GqqnPLIwN2F
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
The operator bool() will be used in the case where we call
MOZ_ASSERT() for const ref of this struct.
MozReview-Commit-ID: tCtpXmPJvV
--HG--
extra : rebase_source : f878c49ab93d8173f9de99b500efc280db886ea3
Servo_GetComputedKeyframeValues is almost the same as what we do in
KeyframeUtils::GetComputedKeyframeValues() for Gecko. Unlike the function
for Gecko, this function does not allocate each ComputedKeyframeValues element,
the allocation has been done before calling Servo_GetComputedKeyframeValues.
MozReview-Commit-ID: LRbriWoal2l
--HG--
extra : rebase_source : 785bb1bc6a62a2f9764fff09f5047942855e3c25