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
--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.
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
Now that DocumentTimeline observes the refresh driver we can use regular
ticks to remove unnecessary animations.
We do this because in a subsequent patch, in order to provide deterministic
enumeration order when ticking animations, we will store animations in an array.
Removing an arbitrary element from an nsTArray is O(n) since we have to search
for the array index first, or O(log n) if we keep the array sorted. If we
destroy a subtree containing n animations, the operation effectively becomes
O(n^2), or, if we keep the array sorted, O(n log n). By destroying during a
tick when we are already iterating over the array, however, we will be able
to do this much more efficiently.
Whether an animation is newly associated with a timeline, or is disassociated
from a timeline, or if it merely has its timing updated, the behavior
implemented in this patch is to simply make sure we are observing the refresh
driver and deal with the animation on the next tick.
It might seem that we could be a lot more clever about this and, for example, if
an animation reports NeedsTicks() == false, not start observing the refresh
driver. There are various edge cases however that need to be taken into account.
For example, if a CSS animation is finished (IsRelevant() == false so that
animation will have been removed from the timeline), and paused
(NeedsTicks() == false), and we seek it back to the point where it is relevant
again, we actually need to observe the refresh driver so that it can dispatch an
animationstart event on the next tick. A test case in a subsequent patch tests
this specific situation.
We could possibly add logic to detect if we need to fire events on the next tick
but the complexity does not seem warranted given that even if we unnecessarily
start observing the refresh driver, we will stop watching it on the next tick.
This patch removes some rather lengthy comments from
AnimationTiming::UpdateTiming. This is, in part, because of the behavior
described above that makes these comments no longer relevant. Other parts are
removed because the Web Animations specification has been updated such that a
timeline becoming inactive now pauses the animation[1] so that the issue
regarding detecting timelines becoming active/inactive no longer applies
since animations attached to an inactive timeline remain "relevant".
[1] https://w3c.github.io/web-animations/#responding-to-a-newly-inactive-timeline
This is not strictly necessary yet but we will want to implement methods
like GetAnimations() on the base class, AnimationTimeline, so we may as well do
that now rather than adding that code to DocumentTimeline and moving it later.
--HG--
extra : commitid : 7GU6Dr9lnPO
extra : rebase_source : d5e788874c72c422b57efbdb81404c79df6d505b