Currently we avoid posting animation restyles when unbinding an element by
removing the element from the document before deleting its animation
collections. As a result, when canceled animations go to post a restyle, they
can't find a pres context and give up posting a restyle.
However, this is problematic for two reasons:
* It means we can't remove such canceled animations from the
PendingAnimationTracker if they are present there (i.e. it regresses the fix
from bug 1223445).
* It means we can't post cancel events for such animations/transitions since we
can't lookup the appropriate AnimationEventDispatcher.
In the next patch in this series we will change that order to fix the above
problems but before we do that, we need to introduce another mechanism to make
sure that we don't post restyles when unbinding an element or else we will
regress bug 1396041.
This patch does that by introducing a flag which causes us to not post restyles
when we are doing DOM surgery. For all other cases we actually _do_ need to post
restyles in order to update the style correctly.
Without this patch, layout/style/crashtests/1396041.html would fail after
applying the next patch in this series.
Differential Revision: https://phabricator.services.mozilla.com/D28021
--HG--
extra : moz-landing-system : lando
A lot of files include `nsIPresShell.h` even though currently they don't
need it. This patch removes the unnecessary inclusions.
Differential Revision: https://phabricator.services.mozilla.com/D25744
--HG--
extra : moz-landing-system : lando
A lot of files include `nsIPresShell.h` even though currently they don't
need it. This patch removes the unnecessary inclusions.
Differential Revision: https://phabricator.services.mozilla.com/D25744
--HG--
extra : moz-landing-system : lando
`*Inlines.h` shouldn't be included by another header file, but `nsPresContext.h`
does it. This causes include-hell which blocks the following fix.
Additionally, it causes an include hell between `PresShell.h` vs.
`nsIPresShell.h` and `nsPresContext.h if `Document.h` includes `PresShell.h`.
Therefore, this patch also solves this include hell with adding
`nsPresContextInlines.h`.
Differential Revision: https://phabricator.services.mozilla.com/D25333
--HG--
extra : moz-landing-system : lando
`*Inlines.h` shouldn't be included by another header file, but `nsPresContext.h`
does it. This causes include-hell which blocks the following fix.
Additionally, it causes an include hell between `PresShell.h` vs.
`nsIPresShell.h` and `nsPresContext.h if `Document.h` includes `PresShell.h`.
Therefore, this patch also solves this include hell with adding
`nsPresContextInlines.h`.
Differential Revision: https://phabricator.services.mozilla.com/D25333
--HG--
extra : moz-landing-system : lando
This is more consistent with what the Rust bits of the style system do, and
removes a pointer from ComputedStyle which is always nice.
This also aligns the Rust bits with the C++ bits re. not treating xul pseudos as
anonymous boxes. See the comment in nsTreeStyleCache.cpp regarding those.
Can't wait for XUL trees to die.
Depends on D19001
Differential Revision: https://phabricator.services.mozilla.com/D19002
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
This change removes directives NS_STYLE_ANIMATION_PLAY_STATE_* and replaces the values with those from a scoped enum called StyleAnimationPlayState.
Differential Revision: https://phabricator.services.mozilla.com/D9382
--HG--
extra : moz-landing-system : lando
For each file touched in this patch, the file had an #include for nsContentUtils.h, but no other mentions of the string "nsContentUtils", nor any mention of its "ScriptBlocker"-related types. So these files likely don't need their nsContentUtils.h include anymore, and we can remove it to get a marginal win on build time/complexity.
Differential Revision: https://phabricator.services.mozilla.com/D3370
--HG--
extra : moz-landing-system : lando
The setup is that AnimationValue only contains physical properties, and
we physicalize when building keyframes and transitions.
MozReview-Commit-ID: 9dI20N0LFrk
Before this change, the test in this commit fails. The received events order
is;
1) cancel
2) transitioncancel
3) transitionstart
4) finish
MozReview-Commit-ID: 8liTFXime6e
--HG--
extra : rebase_source : 3c68ef330b1f263afa2fad9670a30b351b8dbf28
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
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
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
For now, we are going to make _all_ CSS Animations related timer fuzzing
only applicable in Resist Fingerprinting Mode (addressing the last couple
that had not already been configured that way.)
We hardcode their content mix-ins as zero, but leave comments indicating
how they should behave.
MozReview-Commit-ID: KhmV7wO8Pt5
--HG--
extra : rebase_source : 3b087d40b6332d447b442b435ed6fee8993e0145
When CSS animation playState is changed, we should call RequestRestyle(Layer)
to reflect the new state to the compositor just like when animation timing
params are changed.
MozReview-Commit-ID: JNDBco5uuK2
--HG--
extra : rebase_source : cc7de301efdb18a97597d94682ff2329ee1f60d6
Now we sort CSS animation/transition events by scheduled event time prior
to compositor order.
SortEvents() will be a private method in the next patch in this patch
series.
MozReview-Commit-ID: ICkOayquN0f
--HG--
extra : rebase_source : 405c8232e93c54a073c722a4332873af02daa870
Now single AnimationEventDispatcher can handle both CSS animation/transition
events simultaneously. To do this we had to change AnimationEventInfo and
TransitionEventInfo into a single struct, the struct is also named
AnimationEventInfo.
It results we can sort both CSS animation/transition events altogether. Thus
we make sure CSS animation/transition events are sorted by scheduled event time
prior to their composite order (i.e. transitions is prior to animations).
At this moment, we don't sort both events altogether since nsAnimationManager
and nsTransitionManager has an AnimationEventDispatcher respectively. In the
next patch we move AnimationEventDispatcher into nsPresContext, i.e. each
document has an AnimationEventDispatcher without the distinction between
CSS animations and transitions.
Note that, after this patch, we copy all members in InternalTransitionEvent and
InternalAnimationEvent in the copy-constructor of AnimationEventInfo, this
will be fixed once WidgetEvent has move-constructor and move-assignment
(bug 1433008).
MozReview-Commit-ID: 5JAh6N7C6ee
--HG--
extra : rebase_source : 50da76f51cf65cdd1245d93d8b48aaf0ae0ec94b
Now we sort CSS animation/transition events by scheduled event time prior
to compositor order.
SortEvents() will be a private method in the next patch in this patch
series.
MozReview-Commit-ID: ICkOayquN0f
--HG--
extra : rebase_source : 52226c33a511451c31d4c3fef94ff02de8462256
Now single AnimationEventDispatcher can handle both CSS animation/transition
events simultaneously. To do this we had to change AnimationEventInfo and
TransitionEventInfo into a single struct, the struct is also named
AnimationEventInfo.
It results we can sort both CSS animation/transition events altogether. Thus
we make sure CSS animation/transition events are sorted by scheduled event time
prior to their composite order (i.e. transitions is prior to animations).
At this moment, we don't sort both events altogether since nsAnimationManager
and nsTransitionManager has an AnimationEventDispatcher respectively. In the
next patch we move AnimationEventDispatcher into nsPresContext, i.e. each
document has an AnimationEventDispatcher without the distinction between
CSS animations and transitions.
Note that, after this patch, we copy all members in InternalTransitionEvent and
InternalAnimationEvent in the copy-constructor of AnimationEventInfo, this
will be fixed once WidgetEvent has move-constructor and move-assignment
(bug 1433008).
MozReview-Commit-ID: 5JAh6N7C6ee
--HG--
extra : rebase_source : 06ef844f41cfe81b9a629340b5a328c1bed80e8e
Only animationcancel event uses current time, the elapsed time for other
animation events are simply calculated from given animation properties (e.g.
animation-duration, animation-delay, etc.), so they should not be reduced the
precision.
See the table for each elapsed time;
https://drafts.csswg.org/css-animations-2/#event-dispatch
MozReview-Commit-ID: 1KGUAdDHyXV
--HG--
extra : rebase_source : 8bc803ff9e3526396e694082392f9d1454999a0f
We don't need to create AnimationEventParams, we can direcly create
AnimationEventInfo array and move it to dispatcher.
MozReview-Commit-ID: BCzKGAV8VTw
--HG--
extra : rebase_source : f668b27bacb0c929de5b997b5428c3c75e5a8474
