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
2017-10-25 15:34:50 +09:00
Matt Woodrow ext:(%2C%20Miko%20Mynttinen%20%3Cmikokm%40gmail.com%3E%2C%20Timothy%20Nikkel%20%3Ctnikkel%40gmail.com%3E)
This implements the changes specified in these three spec changesets:
8efd180bd9f43ecdfbe5a4f1ad1a60
MozReview-Commit-ID: KFhgZ5ip6BA
--HG--
extra : rebase_source : aa18f8e3fbcd5d96194ff9a5239a3c415622dc2f
This implements the following change to the Web Animations specification:
19b6c33cee
The background to that change is described in the corresponding spec issue:
https://github.com/w3c/web-animations/issues/201
MozReview-Commit-ID: GGA64LG5vT
--HG--
extra : rebase_source : 92c2a60a250071926c2c998dbfadc5979b89cc0c
We could handle this case by dropping the animation from the pause-pending table
but that's an extra hashtable lookup that so far seems to be unnecessary.
I have verified that the crashtest added in this patch fails without the code
changes included here.
MozReview-Commit-ID: Ed6u7WRLD2t
--HG--
extra : rebase_source : 8b175ef2d06b4394f3c51f740a1d305aeea9ed04
(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
Brian Birtles
Matt Woodrow ext:(%2C%20Miko%20Mynttinen%20%3Cmikokm%40gmail.com%3E%2C%20Timothy%20Nikkel%20%3Ctnikkel%40gmail.com%3E)
Hiroyuki Ikezoe
Boris Chiou
Nicholas Nethercote
Wei-Cheng Pan
Emilio Cobos Álvarez
J. Ryan Stinnett
Andrew McCreight
Mantaroh Yoshinaga
Tim Huang
Eric Rahm
Daisuke Akatsuka