If we have a rotate axis whose length is extremely large, we will get an
infinite value, and its normalized vector is a zero vector, instead of an
unit vector, i.e. (x/inf, y/inf, z/inf) == (0, 0, 0).
The solution is: we scale the vector, so the length becomes a finite value,
and we could get a valid unit vector. Therefore, we use
a different normalization method, robust_normalize().
MozReview-Commit-ID: L8SteFe09aO
--HG--
extra : rebase_source : 4568c8bf906a9246e4ef13672a9ed541852b974a
There seem race conditions that we do a paint process when we started observing
the refresh driver but the first tick hasn't happened yet.
MozReview-Commit-ID: KRP8WR644q1
This call was added in bug 929362, but the key factor to fix the bug was just
setting a flag representing that the target frame doesn't allow the animation
running on the compositor and checking the flag in the function whether the
animation can be run on the compositor or not in later ticks. So the call
wasn't necessary in the first place.
The test case here fails without this fix. The test case actually doesn't
observe animation restyle count at all, so it might look a bit awkward in
file_restyles.html, if we add other test cases checking SchedulePaint calls
in future, we will move the tests in a different file.
(The reason there is no animation restyles in this case is that we properly
throttle the animation in this case.)
MozReview-Commit-ID: AyHciRJHM0s
--HG--
extra : rebase_source : f3963336ea9165b0a9c1a662bdac5c645b209219
Web animation event (i.e. finish and cancel event) is solely queued.
MozReview-Commit-ID: h1g3NfcY3c
--HG--
extra : rebase_source : 1a7b09783d193195b886fa3a046198ba3e02dd7b
That's because the target for web animation events (i.e. finish and cancel)
is an Animation instance.
MozReview-Commit-ID: 5xR325FXUo
--HG--
extra : rebase_source : 9bd0623ece1dc449d52db283882fe236dbc11c6d
Normally the refresh driver's time changes in nsRefreshDriver::Tick, and then
DocumentTimeline::WillRefresh is called for the change. But nsRefreshDriver
sometimes updates its own time when their timer changes to the active one.
This patch lets DocumentTimeline update animations in response to the refresh
driver's time updates. And thus this patch prevents animation state and
relevant stuff inconsistencies such as an animation has been finished without
proper processes, e.g. without invalidating frame for the animation.
MozReview-Commit-ID: 42p5BWITQN0
--HG--
extra : rebase_source : 58cc7d8e203a3632b6934b9d778e82e2fe208adb
As for removing an entry, EnsureRemoved is equal to what Contains && RemoveEntry
do, but for consistency we use EnsureRemoved here.
MozReview-Commit-ID: 9qE3YtvmwC8
--HG--
extra : rebase_source : 1681194cd8b9700d46a07a502f7d2f15580918aa
Before this change, we don't acend up frame tree across different documents,
but it's possible that subframe document is scrolled out in the parent document,
if there are animations in such subframes, we should throttle the animations
too.
The test case added here fails without this fix.
MozReview-Commit-ID: EdOEVEwomPc
--HG--
extra : rebase_source : 4d6366cf609d9269ec05b3722f5adb21d940a9e3
Because now we don't try to send the animations on visibility:hidden element.
MozReview-Commit-ID: IFqIc8ewz5T
--HG--
extra : rebase_source : ed031b3a55fd89f74437b71812f90dfc1825e823
Even if we unthrottled the invisbile animations to update the overflow region,
we don't need to send the animations to the compositor since the scroll bar
updates caused by the overflow should have been finished before sending
animations to the compositor.
MozReview-Commit-ID: GtKdPfBSyRB
--HG--
extra : rebase_source : 3b15f4578ed60740c1409304fe35ecd4f53fbd5b
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
The styles for placeholder frames differ from the styles for the real frames so
that the styles don't have visibility:hidden even if the parent has
visibility:hidden style.
The placeholder style is resolved by ServoStyleSet::ResolveStyleForPlaceholder
in nsCSSFrameConstructor::CreatePlaceholderFrameFor.
MozReview-Commit-ID: GgFn5VJOvcl
--HG--
extra : rebase_source : a32771f5bb6c6862e483fe36a2060d604ee2413d
When an animation targets a CSS property that could cause a containing block to
be generated for its descendants, this containing block must be generated even
if the particular property values used by the animation would not normally
trigger generation of a containing block (e.g. transform: none). This is due
to the implicit application of will-change defined in CSS Animations[1] and Web
Animations[2].
Since this containing block is generated at the start of the animations, we can
throttle animations that produce the UpdateContainingBlock change hint for
animations that are not visible since they shouldn't have any further side
effects beyond the generation of containing blocks (which have already happened).
[1] https://drafts.csswg.org/css-animations/#animations
[2] https://drafts.csswg.org/web-animations-1/#side-effects-section
Unfortunately perspective animations starting with 'none' and transform
animations from 'none' to 'none' don't create a containing block (bug 1470349
and bug 1470370). That doesn't block the optimization in this patch, however,
since those bugs occur regardless of element visibility.
MozReview-Commit-ID: 8rTl8dShHrD
--HG--
extra : rebase_source : 886b003d0f3c555a12baf0de81b4130ef2d71e82
In the case where the target element is scrolled out or visibility:hidden and
has no visible descendants, we can treat nsChangeHint_UpdateOverflow just like
transform animations which produce nsChangeHint_UpdatePostTransformOverflow,
i.e. unthrottle the animations periodically if the target element is inside a
scrollable element. Some transform animations produce UpdateOverflow hint,
so it would be really nice to optimize the hint.
MozReview-Commit-ID: E1MgPZRi8mW
--HG--
extra : rebase_source : d29a29e137742f88a64b3b18a5a7d4e64e76f54f
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
The styles for placeholder frames differ from the styles for the real frames so
that the styles don't have visibility:hidden even if the parent has
visibility:hidden style.
The placeholder style is resolved by ServoStyleSet::ResolveStyleForPlaceholder
in nsCSSFrameConstructor::CreatePlaceholderFrameFor.
MozReview-Commit-ID: GgFn5VJOvcl
--HG--
extra : rebase_source : 5ea5b101fff03cb2a834e218f4e6df0a0527dfdb
When an animation targets a CSS property that could cause a containing block to
be generated for its descendants, this containing block must be generated even
if the particular property values used by the animation would not normally
trigger generation of a containing block (e.g. transform: none). This is due
to the implicit application of will-change defined in CSS Animations[1] and Web
Animations[2].
Since this containing block is generated at the start of the animations, we can
throttle animations that produce the UpdateContainingBlock change hint for
animations that are not visible since they shouldn't have any further side
effects beyond the generation of containing blocks (which have already happened).
[1] https://drafts.csswg.org/css-animations/#animations
[2] https://drafts.csswg.org/web-animations-1/#side-effects-section
Unfortunately perspective animations starting with 'none' and transform
animations from 'none' to 'none' don't create a containing block (bug 1470349
and bug 1470370). That doesn't block the optimization in this patch, however,
since those bugs occur regardless of element visibility.
MozReview-Commit-ID: 8rTl8dShHrD
--HG--
extra : rebase_source : f2f89c8ad074f1ad73ebd5652311d22e71cf7344
In the case where the target element is scrolled out or visibility:hidden and
has no visible descendants, we can treat nsChangeHint_UpdateOverflow just like
transform animations which produce nsChangeHint_UpdatePostTransformOverflow,
i.e. unthrottle the animations periodically if the target element is inside a
scrollable element. Some transform animations produce UpdateOverflow hint,
so it would be really nice to optimize the hint.
MozReview-Commit-ID: E1MgPZRi8mW
--HG--
extra : rebase_source : d29a29e137742f88a64b3b18a5a7d4e64e76f54f
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
They require destructor of Animation, but that is an incomplete type in
AnimationEffect.h, and AnimationEffect.h cannot include Animation.h
because the latter already includes the former.
MozReview-Commit-ID: AunD7dI1QN5
--HG--
extra : rebase_source : c9331eb5186b09666419e0b7ab12517beb07793f
It's possible that both this_weight and other_weght have calculation errors
which are approximately equal to f64::EPSILON.
MozReview-Commit-ID: 8OddG9rI3qd
--HG--
extra : rebase_source : 9c22d17dcfb8efea7276864502344dc4981c358a
For example, we don't run transform animations on large frames but once
the frame size is small enough we should run transform animations on the frame.
MozReview-Commit-ID: DkfB9g2Gcdi
--HG--
extra : rebase_source : 93a884c3063d4a6c2626e6695583664b24fe11c8
Same approach as the other bug, mostly replacing automatically by removing
'using mozilla::Forward;' and then:
s/mozilla::Forward/std::forward/
s/Forward</std::forward</
The only file that required manual fixup was TestTreeTraversal.cpp, which had
a class called TestNodeForward with template parameters :)
MozReview-Commit-ID: A88qFG5AccP
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
Previously we used the tweakExpectedRestyleCount function (replaced by the
waitForAnimationReadyToRestyle function in the previous patch) only in cases
where we were actually expecting restyles to happen. For cases where we don't
expect restyles, i.e. cases where we assert the restyle count is zero, we
didn't use this method meaning we didn't bother checking if there was a restyle
expected for the current frame or not.
Since we normally wait for 5 frames anyway before checking that there have been
no restyles, failing to count the number of frames and waiting only 4 frames is
not a problem. However, if a new test were added that just copied this code and
only waited one frame, it might fail to test what it intended. So, to avoid
possible future bugs and in order to be more consistent with tests that do
expect restyles, this patch replaces a number of uses animation.ready with
waitForAnimationReadyToRestyle.
MozReview-Commit-ID: 7qBmobTKolh
--HG--
extra : rebase_source : baa272102fed7a66cc4fc89f6d63ba0333087a2d
And replace tweakExpectedRestyleCount with the function.
MozReview-Commit-ID: 96jC9looyZq
--HG--
extra : rebase_source : 7dae8b258b874a9b366767a6e49de83bf2caccc9
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
Apart from whitespace / test description tests this patch also drops an
assertion about the animation playState since it seems unrelated to the purpose
of that particular test.
--HG--
extra : rebase_source : 73be030dd1dc98ae1facd9c2b80dd1b5bcbf04eb
As well as addressing a few FIXMEs this patch drops the checking of start times
since that seems out of scope for this file and is covered elsewhere (I believe
we only added it at first to bootstrap this work).
--HG--
extra : rebase_source : daa067147d6833880deb59b3d270ca122999a64f
This patch updates the tests in this file as follows:
* startTime of a newly created (play-pending) animation is unresolved
-> Covered by 'startTime of a play-pending animation is unresolved'
in wpt/web-animations/interfaces/Animation/startTime.html
However, it would be useful to have a test a new CSS animation is
play-pending so I have extended the test in test_animation-playstate.html
to cover this.
* startTime of a newly created (pause-pending) animation is unresolved
-> Covered by 'startTime of a pause-pending animation is unresolved'
in wpt/web-animations/interfaces/Animation/startTime.html
* startTime is resolved when running
-> Covered by 'startTime is resolved when running'
in wpt/web-animations/interfaces/Animation/startTime.html
* startTime is unresolved when paused
-> Moved to wpt/web-animations/timing-model/animations/pausing-an-animation.html
* startTime while pause-pending and play-pending
-> Moved to wpt/web-animations/timing-model/animations/pausing-an-animation.html
* startTime while play-pending from finished state,
startTime while play-pending from finished state using finish()
-> Merged and moved to wpt/web-animations/timing-model/animations/playing-an-animation.html
* Pausing should make the startTime become null
-> Simplified and merged into the test for 'startTime is unresolved when
paused' / 'Pausing clears the start time' test in
wpt/web-animations/timing-model/animations/pausing-an-animation.html
* Sanity test to check round-tripping assigning to a new animation's startTime
-> Updated and left.
* Skipping forward through animation
-> This is really testing two things:
(a) That you can seek a CSS animation using the start time.
For this it makes sense to have a separate test that also checks that
the computed style is updated (like we have for current time).
(b) That seeking a CSS animation using the start time triggers
dispatching events.
This patch splits the above into two separate tests.
* Skipping backwards through animation,
Redundant change, before -> active, then back,
Redundant change, before -> after, then back,
Redundant change, active -> before, then back,
Redundant change, active -> after, then back,
Redundant change, after -> before, then back,
Redundant change, after -> active, then back
-> All these tests are really just exercising event dispatch which is
already covered by test_event-dispatch.html.
Provided we have a test that checks that events are dispatched when
setting the startTime we don't need to test each combination again since
we have tests for each of these combinations already when using the
currentTime to seek and we can assume UAs are following the same code
path at this point.
As a result this patch drops these tests.
* Setting startTime to null
-> Covered by 'Setting an unresolved start time sets the hold time'
in wpt/web-animations/timing-model/animations/setting-the-start-time-of-an-animation.html
* Animation.startTime after pausing
-> Covered by the new 'Pausing clears the start time' test in
wpt/web-animations/timing-model/animations/pausing-an-animation.html
* Animation.startTime after canceling
-> Merged into
wpt/web-animations/timing-model/animations/canceling-an-animation.html
and made it follow the spec a little more closely (which requires
clearing the start time and hold time).
--HG--
extra : rebase_source : 9bb3d82e18e5c2d9654576502a1d4263a1e46daa
Although many of these tests are similar to tests in the Web Animations
web-platform-tests test suite they focus on the interaction with
animation-play-state and so are probably worth keeping.
There are two exceptions that I felt were worth changing:
* The test for the handling of a ready promise on an aborted pause. I could not
find a similar test in the Web Animations wpt and the test is not really
particular to CSS animations so this patch moves it to Web Animations wpt.
* The test for the resolution value of the ready promise for a paused animation
is covered by the "A pending ready promise should be resolved and not replaced
when the animation is paused" in pausing-an-animation.html in the Web
Animations wpt (although peripherally) and that seems like the better place
for this test anyway (it is not specific to CSS animations) so I have simply
deleted it from this file.
--HG--
extra : rebase_source : b803572692c70fced551d4343ac241068b6f0057
This mostly just involves using promise_rejects to simplify some test code.
The change to the test description of the last test might seem like it is giving
it the opposite meaning but the original test name was "Test finished promise
changes when animationPlayState set to running"[1], and it is about testing
that there are NO changes but that got lost when the "Test" part of the
description was dropped.
[1] https://searchfox.org/mozilla-central/rev/cb846d13d3f9ec5d38ace93a74f749a18e9c67f5/dom/animation/test/css-animations/test_animation-player-finished.html#287
--HG--
extra : rebase_source : e318bd236f522e612a8717c4b7b871b1dd74ed54
These tests are all covered elsewhere:
* The "Test exceptions when finishing infinite animation" test is covered by
the "Finishing an infinite animation throws" test in
finishing-an-animation.html in the Web Animations web-platform-tests.
* The "Test finish() while paused" test is covered by the "Finishing a paused
animation resolves the start time" test in finishing-an-animation.html in
the Web Animations web-platform-tests.
* The "Test finish() while pause-pending with positive playbackRate" test is
covered by the "Finishing a pause-pending animation resolves the pending
task immediately and update the start time" test in
finishing-an-animation.html in the Web Animations web-platform-tests.
* The 'Test finish() while pause-pending with negative playbackRate" test is
covered by the "Finishing a pause-pending animation with negative playback
rate resolves the pending task immediately" test in
finishing-an-animation.html in the Web Animations web-platform-tests.
In fact, it very much looks like these tests were copied to Web Animations'
web-platform-tests at some point without deleting the original.
--HG--
extra : rebase_source : d63b1c3ca7548e7f4f27c607e4671691094ddd86
A number of these tests are redundant with other tests or are otherwise
unnecessary. Other tests should be moved to a more appropriate file.
Some notable examples:
* A number of the tests relate to dispatching events in various phases and have
been moved to test_event-dispatch.html.
* The "Seeking finished -> paused dispatches animationstart" test is covered
by the "After -> Active" test in test_event-dispatch.html (which also
operates on a paused animation).
* The "Animation.currentTime clamping" is really just testing finishing
behavior and is covered by the updating-the-finished-state.html tests in the
Web Animations web-platform-tests (specifically the "Updating the finished
state when playing past end" test).
* Likewise for the "Animation.currentTime clamping for reversed animation"
test.
--HG--
extra : rebase_source : 949ec7e12396fa97c741c7cc90abb3ff64cc7ab7
Some of these names will make more sense after the renaming of files towards the
end of this patch series.
Also a couple of files do not have titles added since they will be subsequently
removed.
--HG--
extra : rebase_source : 6ba046f9c1cc2e062d5aa7f7a49b791ef7ee7e83
We will remove animation.effect.timing in the next patch.
MozReview-Commit-ID: EyeFNM81NbN
--HG--
extra : rebase_source : 9fe5eb0e5d141ffffa017db255328c742a059611
Factoring out this method makes the code a little easier to read, particularly
when in the next patch in this series we add
a TimingParams::MergeOptionalEffectTiming method.
MozReview-Commit-ID: 5AU6IfN2grZ
--HG--
extra : rebase_source : f90614c7dd03413b4ce05d62d3ac73f0ba0e7dc3
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
In pseudo element cases mTarget->mElement is the parent element of the pseudo,
thus we inefficiently use the parent frame and walked through parent
continuations.
MozReview-Commit-ID: DsNRXaM346D
--HG--
extra : rebase_source : e62eeff02897ca08e800c1d807f81a0d4cf38dd1
In FindAnimationsForCompositor(), we can ensure
EffectCompositor::GetAnimationElementAndPseudoForFrame doesn't return nullptr
since EffectSet::GetEffectSet(const nsIFrame*) at the top of
FindAnimationsForCompositor() also uses GetAnimationElementAndPseudoForFrame.
MozReview-Commit-ID: CtWdUt40Zyx
--HG--
extra : rebase_source : 7ea1058f4fb740ca35c2ebdc8d2f69d7b634a257
For table element nsDisplayTransform's mFrame is the primary frame not style
frame.
MozReview-Commit-ID: 9BMSpuGE7lC
--HG--
extra : rebase_source : 19edd8978165cfa3904dcabea3e382e9b7c16ee3
GetAnimationFrame is bit ambiguous, the name should match what we call it.
MozReview-Commit-ID: GuyhVrUFgiW
--HG--
extra : rebase_source : 1120e34aa3fdd20cf26552fda01d1a473e3ffff0
In bug 1237454, we introduced a new change hint that is produced when
visibility property is changed from 'visible' to 'hidden' or from 'hidden'
to 'visible'. Animations producing this new change hint can be throttled
if the animation element is out-of-view, but can not be throttled in the case
where the element is in-view. In the bug, a test case for a visibility change
animation on out-of-view element was added, but no test for in-view case was
added.
MozReview-Commit-ID: BhiRm13rfRr
--HG--
extra : rebase_source : 264954ff349d5a9c5a00b940b2eaf2045f0952ae
The test added in this patch fails without the corresponding code changes
(specifically the second gGetComputedTimingTests test fails the comparison of
the 'easing' member).
MozReview-Commit-ID: 9eyXruVrPuN
--HG--
extra : rebase_source : 927f55c0670bf770e03d38eb876202efbb700c1e
On WebRender, the animation on the visibility hidden element runs on the
compositor somehow.
MozReview-Commit-ID: 77dVlIeFQ3u
--HG--
extra : rebase_source : 2b93833e9bf5ed17f3e4ee5306bdcfd57e3c87a4
Note that we have to calculate animation values if there is another animation
since the other animation might be 'accumulate' or 'add', or might have a
missing keyframe (i.e. the calculated animation values will be used in the
missing keyframe).
MozReview-Commit-ID: rQyS9nuVJi
--HG--
extra : rebase_source : 6ddc70308e223a709eba9c4c2f05e42bbc0f3160
The old name no longer makes sense, since it no longer exports an spawn_task
symbol, and add_task is what we really care about.
MozReview-Commit-ID: IE7B8Czv8DH
--HG--
rename : testing/mochitest/tests/SimpleTest/SpawnTask.js => testing/mochitest/tests/SimpleTest/AddTask.js
extra : rebase_source : 03bca5aa69a7625a49b4455a6c96ce4c59de3a5a
Animation::FlushStyle() gets called only for CSS animations/transitions'
playState changes in JS or ready Promise for CSS animations. In either case
throttled animation state, which is, to be precise, transformed position or
opacity value on the compositor, doesn't affect those results.
The first test case for CSS animations and the first test case for CSS
transitions in this patch fail without this fix.
MozReview-Commit-ID: EVym4qputL4
--HG--
extra : rebase_source : 12524c7db1d59da69687bb123fc65ad4301f5527
The flag was introduced in bug 1322291 to prevent recursive calls of
KeyframeEffectReadOnly::ComposeStyle() on the old style system. On the
new style system we never call the function recursively.
MozReview-Commit-ID: L5gb8G3bl4M
--HG--
extra : rebase_source : 3b01c2c3ff97b8890bf13095dd32b834270d00df
Note that on the new style system (a.k.a stylo) the test case hasn't caused
any assertions.
MozReview-Commit-ID: AALHnuW48Rb
--HG--
extra : rebase_source : 8253507eff2522bcc4ccc155aae5c1307a81421d
Original patch by Ethan Lin <ethlin@mozilla.com>.
MozReview-Commit-ID: AAIaskIsz9x
--HG--
extra : rebase_source : 879144b98467f47867d66f2806d7d31dbcf2bc7b
This patch adds three test cases;
1) Animation on position:absolute element in a zero-height iframe
This animation should be throttled.
2) Animation on a non-zero width and hight position:absolute element but whose
parent has a zero height
This animation should NOT be throttled since the animation is visible
3) Animation on a zero-height position:absolute element whose parent also has
zero height.
This animation should be throttled since the animation is invisible
The first test fails without this fix and passes with the fix.
The second one passes regardless of the fix
The third one is marked as 'todo' since it doesn't pass with this fix.
MozReview-Commit-ID: 8pNUFQ71ivj
--HG--
extra : rebase_source : d1d37e5324247efc20a39d86a0f8849450cc7533
This function will be used for checking restyle counts in an iframe
in the next patch.
MozReview-Commit-ID: 2PPjJTzXMXH
--HG--
extra : rebase_source : 4f3b1c37580b0d382ff9c07d81950542d8515bb1
This patch basically does:
* remove StyleSetHandle and its corresponding files
* revisit #includes of related header files and change correspondingly
* change nsIPresShell::mStyleSet to be UniquePtr<ServoStyleSet>
* change the creating path of ServoStyleSet to pass UniquePtr
* change other mentions of StyleSetHandle to ServoStyleSet*
* remove AsServo() calls on ServoStyleSet
Some unfortunate bits:
* some methods of (Servo)StyleSet only accepts ServoStyleSheet while
many places call into the methods with StyleSheet, so there are many
->AsServo() added to sheets
MozReview-Commit-ID: K4zYnuhOurA
--HG--
extra : rebase_source : 459e8efeb171adad089d94272e143e8c244bd279
extra : source : 65ba2f174fcf7dba4e59c00ee8908b1bd0820a48
In bug 1444177, I did accidentally replace the frame count with the tweaked
count. The tweaked count represents that animation restyling should happen
the tweaked count times during *not-yet-tweaked* frame count.
MozReview-Commit-ID: 1QmH5xaYexL
--HG--
extra : rebase_source : fc32bdccf6cdeafcb178b7f675e88038217f658c
The aSamePointerStructs argument is unused now.
Also, aIgnoreVariables can be true everywhere now, since variable changes can't
generate change hints, and anonymous boxes and such don't care about whether
they really changed or not.
Only one caller cares about struct equality, and that already compares variables
manually as an optimization on the rust side.
We had this optimization inconsistently in some cases but not others.
MozReview-Commit-ID: F2EISKlxR3K
