Animation::UpdateTiming takes a SyncNotifyFlag parameter. This is passed to
UpdateFinishedState where it determines how we handle finish actions.
If it is async we queue a microtask where we re-evaluate if the animation is
finished or not before queuing events / resolving promises.
That allows code like the following to _not_ trigger finish events:
```
const animation = elem.animate({...}, 1000);
animation.currentTime += 1000;
animation.effect.updateTiming({ duration: 2000 });
```
(Since the check that the animation is finished will run in a microtask _after_
the call to updateTiming.)
When the flag is "sync" we still don't _actually_ run the finish actions
entirely synchronously: the finished promise is resolved synchronously, but
resolving a promise actually queues a microtask for each callback. Likewise, the
finish event is queued synchronously, but not dispatched.
Since there should be no opportunity for script to run between when we call
Animation::Tick and when we run the next microtask checkpoint (currently at the
end of DocumentTimeline::WillRefresh but that will change slightly in the next
patch in this series) there is no need to introduce the extra "async" microtask
for re-evaluating an animation's finished state. Instead it should be possible
to use the "sync" finishing behavior. Such a change should be unobservable to
Web content but will reduce indirection somewhat.
Differential Revision: https://phabricator.services.mozilla.com/D30318
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
Animation::Cancel calls UpdateTiming() which in turns runs the procedure to
update the finished state. However, the spec[1] doesn't require that.
Furthermore, calling UpdateTiming here hides the fact that we end up triggering
a restyle.
It would be better to move the parts of UpdateTiming we require into Cancel
itself so that we align better with the spec and to make it a bit more clear
what side-effects of UpdateTiming we actually rely on.
[1] https://drafts.csswg.org/web-animations-1/#cancel-an-animation
Differential Revision: https://phabricator.services.mozilla.com/D28020
CancelNoUpdate actually can and does trigger restyles via its call to
KeyframeEffect::NotifyAnimationTimingUpdated so at very least its name is wrong.
Furthermore, we actually want canceling to trigger restyles in most cases since
when an animation is canceled we need to trigger a subsequent restyle to apply
the (no-longer-animated) result.
This wasn't necessary when CancelNoUpdate was first introduced but since then we
have introduced the Servo style engine where we use a separate traversal to
apply the result from creating/deleting/modifying animations.
This change will mean that we now trigger a "layer" restyle when canceling an
animation when we previously didn't. That, however, seems more correct if
anything.
This patch also makes CancelFromStyle no longer virtual since it doesn't seem
necessary anymore (perhaps because we now point to the concrete type:
CSSAnimation/CSSTransition from nsAnimationManager/nsTransitionManager whereas
previously we didn't).
Differential Revision: https://phabricator.services.mozilla.com/D28019
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
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
If `Document::GetShell()` returns `PresShell*` rather than `nsIPresShell`, it's
a good step to deCOMTaminate `PresShell`.
This patch makes `Document.h` stop including `nsIPresShell.h` since
`nsIPresShell.h` includes `Document.h` indirectly and that causes bustage
when we make `Document::GetShell()` return `PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25332
If `Document::GetShell()` returns `PresShell*` rather than `nsIPresShell`, it's
a good step to deCOMTaminate `PresShell`.
This patch makes `Document.h` stop including `nsIPresShell.h` since
`nsIPresShell.h` includes `Document.h` indirectly and that causes bustage
when we make `Document::GetShell()` return `PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25332
We use DisplayItemType as the input of HasAnimationsForCompositor, and
nsCSSPropertyIDSet as the input of GetAnimationsForCompositor.
The caller of HasAnimationsForCompositor just wants to check if there is
any compositor animation for a display item, so we can replace it by the
display item, and get the properties from this display item.
However, the caller of GetAnimationsForCompositor may use a subset of
transform-like properties for getting scale factors, or use all the
transform-like properties for sending all transform animations to the
compositor thread.
Depends on D19630
Differential Revision: https://phabricator.services.mozilla.com/D19628
nsIFrame::BuildDisplayListForStackingContext() will check the existence
of transform animations, so we need to update
nsLayoutUtils::HasAnimationsOfPoperty(). However, checking only
eCSSProperty_transform is not enough. We have to check all the transform-like
properties. Therefore, we update these functions to accept a property
set as the argument, and pass a collection of transform-like properties
into them.
Differential Revision: https://phabricator.services.mozilla.com/D20412
Bug 1517241 renamed nsIDocument to mozilla::dom::Document but unfortunately in
the process it messed up the ordering of includes which, according to the coding
style[1], should be alphabetically sorted.
Also, in TimingParams.cpp it didn't add the dom::* prefix so when the unified
build chunking changes, if the "using namespace mozilla::dom" declaration
disappears from the chunk, it will fail to build.
[1] https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#CC_practices
Depends on D15902
Differential Revision: https://phabricator.services.mozilla.com/D15903
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.
As discussed here:
https://github.com/w3c/csswg-drafts/issues/2691
We have a similar check in SetCurrentTime (with the exception that, according to
the spec, this behavior applies to either play OR pause pending, instead of just
pause-pending) so this patch tries to match the comment and format of that
check.
Differential Revision: https://phabricator.services.mozilla.com/D2410
When the pending animation having no target element sets a new effect having
a target element associated with a document, PendingAnimationTracker has to
start tracking the animation regardless of mPendingReadyTime.
MozReview-Commit-ID: DxmbXtLhjCT
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
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
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
This pref was introduced in case we encountered compatibility issues from
changing the return value of Animation.playState (bug 1412765). Now that the
change to Animation.playState has shipped to release channel without any known
problems we should drop this pref.
MozReview-Commit-ID: CwMWRRtIf6u
Now AnimationEventDispatcher ensures that the refresh driver's next tick
happens for cancel event, so we don't need to re-observe the timeline
(it happens in UpdateTiming) once after removing the animation from the
timeline.
MozReview-Commit-ID: 7ivclmYIkPa
Now AnimationEventDispatcher ensures that the refresh driver's next tick
happens for cancel event, so we don't need to re-observe the timeline
(it happens in UpdateTiming) once after removing the animation from the
timeline.
MozReview-Commit-ID: 7ivclmYIkPa
