(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
When we set the playback rate to zero on a play-pending animation that is
resuming from an aborted pause we can arrive in a state where both the start
time and hold time are resolved. However, we previously added an assertion that
only one of these is ever set at a time.
Part of the assertion is warranted since that method contains the following
code:
if (mStartTime.IsNull()) {
mStartTime = StartTimeFromReadyTime(aReadyTime);
if (mPlaybackRate != 0) {
mHoldTime.SetNull();
}
}
Here StartTimeFromReadyTime requires a non-null hold time. So either mStartTime
or mHoldTime needs to be non-null. The requirement that only one or the other be
non-null, however, is not in the spec and not necessary (as the test cases in
this bug show).
What this assertion does bring to light, however, is that in the case where we
have *both* the start time and the hold time, we need to consider whether to use
the start time as-is, or calculate it from the hold time.
I have filed the following spec issue for this:
https://github.com/w3c/web-animations/issues/200
MozReview-Commit-ID: CTCT7Up1E5n
--HG--
extra : rebase_source : 95233f7cd2bc3c4bcc56615d8387fe54852986c1
As required by the recent spec change:
d696468777
MozReview-Commit-ID: Ev6kUk1uLAY
--HG--
extra : rebase_source : 70f8ca3143a8b3bb4e03016b9989925d5a328049
nsFrame::SchedulePaint() invokes InvalidateRenderingObservers, and
InvalidateRenderingObservers ends up posting change hints during we are
processing sequential tasks for animations, but we don't allow posting any
change hints while we are in the middle of restyling process.
Though the change hints posted by InvalidateRenderingObservers are not harmful
in this case since the change hints will be processed in a second post
traversal without problems. That's said, InvalidateRenderingObservers stuff
should be processed in display list based invalidation anyway (bug 1284053).
MozReview-Commit-ID: GKVRZ98lvEN
Otherwise, if getKeyframes() returns an empty array, we don't check each keyframes
at all.
MozReview-Commit-ID: LSBIgetZq2G
--HG--
extra : rebase_source : cc24d093a1e0c9223ac696e44d297602016189a2
Skips flushing current document if the target of getComputedDOMStyle cannot be
affected by any pending restyles.
MozReview-Commit-ID: C87HDIDvOth
--HG--
extra : rebase_source : 064880493f9aac2599689cdd0749200bb579c60b
If we don't increment the reference count for the Atom in servo side, it's
possible to try to release the Atom in servo side even if we have already
released in gecko side. When it happens, nsIAtom::mKind is no longer reliable.
MozReview-Commit-ID: GrxbcYxowRB
--HG--
extra : rebase_source : 94e054e3357b31e398e8e5e81522dab3019c561c
The SchedulePaint() ends up calling
nsSVGEffects::InvalidateDirectRenderingObservers, it doesn't need for retained
display list, and causes harmful restyle events for stylo.
We will call ScheulePaint without involing InvalidateDirectRenderingObservers
later in another bug.
MozReview-Commit-ID: 10V9JLHZmCs
--HG--
extra : rebase_source : 664718eb91e973a4619847e4bfa94327e410f364
The overall progress is factored in iteration start, so even if
TimingParams.mIterations is less than UINT64_MAX, it will exceed UINT64_MAX.
MozReview-Commit-ID: CEOYAGsCoIE
--HG--
extra : rebase_source : 54ed450ebd0218ee2cac9f27125601c6575ee1a5
Because our ComputedTiming.mCurrentIteration is uint64_t.
MozReview-Commit-ID: FjbhEvTUMr4
--HG--
extra : rebase_source : d8ba72c914aac6661f0a5a21885505f94844ce38
When an animation is newly created while the same property transition is
running, the transition style rule persists until we call RequestRestyle() for
transitions level. That means if user calls getComputedStyle for the property
right after creating animation, the style obtained by getComputedStyle still
included the transitions level rule. As a result, the transitions level style
overrides newly created animation style until the next normal restyling process
happens (i.e. process transition level restyle request). Vice versa, in the
case where an animation is removed, transitions level style does not appear
until the next normal restyling.
This patch fixes this problem by trigerring a resyle of the transitions level
when an animation is created or removed.
MozReview-Commit-ID: HY6amLmDHTi
--HG--
extra : rebase_source : 67e58dc9a6c695299c3eef684bf7357153c5168b
Automation also uses env vars to change the Stylo mode, so reading the pref is
not enough. Change the test to `isStyledByServo` which covers all cases.
MozReview-Commit-ID: KLh42b4roF4
--HG--
extra : rebase_source : f77e78694d00489d4e5c7d7f4eaffca0610f128a
Replace it with NS_INTERFACE_MAP_BEGIN_CYCLE_COLLECTION, because it
has been the same for a while.
MozReview-Commit-ID: 5agRGFyUry1
--HG--
extra : rebase_source : 5388c56b2f6905c6ef969150f0c5b77bf247624d
This test called waitForPaints() after creating an animation, but waitForPaints()
didn't wait for a MozAfterPaint event actually since
DOMWindowUtils.IsMozAfterPaintPending which is checked a MozAfterPaint event has
been queued return false[1]. (i.e. This test didn't wait for a MozAfterPaint)
This is related to bug 1341294. If gecko can receive a MozAfterPaint
corresponded to own paint, waitForPaint() does not need to check for
DOMWindowUtils.IsMozAfterPaintPending.
This patch is a workaround until bug 1341294 is resolved.
[1] http://searchfox.org/mozilla-central/rev/5696c3e525fc8222674eed6a562f5fcbe804c4c7/testing/mochitest/tests/SimpleTest/paint_listener.js#60
MozReview-Commit-ID: 6Rnv8MBP6Se
--HG--
extra : rebase_source : 052f62b01df819961040f6652954e1068f86fc47
Adopt from Tor #16337.
This patch makes Animation API to report a rounded time when 'privacy.resistFingerprinting'
is true. The Animation API uses AnimationUtils::TimeDurationToDouble() to convert
its time duration into a double value and reports it when someone tries to query
time through Animation API. So, we use nsRFPService::ReduceTimePrecisionAsMSecs()
inside this method to round the time in the scope of the millisecond.
MozReview-Commit-ID: 8o01G6AlAu9
--HG--
extra : rebase_source : e2d52f04c1d63accb786f6cf9b1a102607eed517
We should not be declaring forward declarations for nsString classes directly,
instead we should use nsStringFwd.h. This will make changing the underlying
types easier.
--HG--
extra : rebase_source : b2c7554e8632f078167ff2f609392e63a136c299
This is a temporary step until we implement bug 1391537. It is needed to
maintain consistent behavior with Gecko and provide sensible output,
particularly in the case where we have longhands whose values are drawn from
unparsed shorthands.
MozReview-Commit-ID: 9aD2tsLagBp
--HG--
extra : rebase_source : cdabb26be17b96a574ea8b2e8093e11abb1af430
calc() serialization in stylo changed to align to the spec more closely (modulo percentage order).
See the linked issue.
MozReview-Commit-ID: GyzZvdumMSe
In Servo, the max value for 'translate' is different from normal float since
is using Au ( AppUnit ). The value which we introduced as MAX_AU_PX
( 1.78957e+7 ) in this test is calculated by following mechanis.
1. Like this time, if the value is larger than max float, stored into specified
value as infinity by parsing.
2. Then, when converts to the computed value Au from the specified value
(infinity), ABSOLUTE_LENGTH_MAX (1 << 30) = 1073741824 stores into the Au.
[1]
3. Finally, when get the PX value, returns the value which devided by
AU_PER_PX ( 60 ). This value is 1.78957e+7.
[1] to_au_round() method
https://searchfox.org/mozilla-central/source/servo/components/style/values/specified/length.rs#249
MozReview-Commit-ID: BVfDhOKXaWw
--HG--
extra : rebase_source : e55be1f42d9198c35bb8f29882ff19ec9de8f2fa
The serialization of the value in getKeyframes() on both Gecko and Servo is
different, especially 'initial', 'inherit' and 'unset' on discrete animation.
Gecko returns those value as is, but Servo returns computed value.
We are understanding computed value (Servo) is right, so we change expected
values for them. Also, we skip them if this test is running on Gecko.
MozReview-Commit-ID: 4GFpCpec0eP
--HG--
extra : rebase_source : 8bb9fc670fb7ffd56935cdfb4f038be334782de7
Since we made -moz-appearance animatable, append to the moz prefixed properties
test.
MozReview-Commit-ID: 9tdouU1umEB
--HG--
extra : rebase_source : 79e9639360461452249ce54ff538294f25b6cd4f
From the official link for -moz-force-broken-image:
A value of 1 means that the broken image icon is even shown if the image has
an alt attribute. A value of 0 only displays the alt attribute.
It's really ambiguous how we handle other values. Actually stylo's parser
rejects other values. We should use the valid values for this test.
MozReview-Commit-ID: CzmIvsmauke
--HG--
extra : rebase_source : a6387e07b3578cf811bd17f772d791ec73bfa1e7
Unlike Gecko, Stylo currently invokes a needless RequestRestyle(Standard)
for this test case (bug 1388560). For this reason, the check right after
re-attaching the orphaned element passes accidentally.
MozReview-Commit-ID: JUG1dgMUQEX
--HG--
extra : rebase_source : a86d72a41c160edc30f83d82179ebe1226b842de
Actually we have a chance to run styling process when we attach an orphaned
element to a document in this test setup. Precisely, we can process a restyle
between rAF callbacks and Promise.then() callback for waitForAnimationFrames().
So if we call RequestRestyle(Layer) when we attach the element to the document
(bug 1388557), the animation starts restyling in the first frame. *BUT* this
behavior will also change once our micro tasks handling becomes the HTML spec
compliance (bug 1193394). When the micro tasks handling changes, we should also
fix a bunch of test cases and test utilities in bug 1388557.
MozReview-Commit-ID: GyH1ofGhXOP
--HG--
extra : rebase_source : 3536c315960150960fd43286b205c03c584d53ca
DOMWindowUtils.isStyledByServo checks not only the preference value but also
STYLO_FORCE_ENABLED value. This is important especially when we run test on
our CI. On our CI, the preference value is false but just STYLO_FORCE_ENABLED
is set.
MozReview-Commit-ID: FKEd5LFwcxf
--HG--
extra : rebase_source : 1ffd8a68a8339babed14f441bf2d69c9ffd9e3ee