This patch check whether nsCaret shows in scroll frame. If yes, touch
caret will show, and its position will be clamp to scroll frame as
before. Otherwise, we hide it since the nsCaret will not be seen in this
case.
When loading an html, painting is suppressed in PresShell. Therefore the
rect of nsCaret or the rect of nearest ancestor scroll frames will not
be correct. Touch caret will hide incorrectly because it cannot get the
necessary rect to calculate its position.
I added a condition in IsDisplayable() to skip when painting is
suppressed. Touch caret should sync its visibility with nsCaret again
when painting is unsuppressed, and those rects needed by touch caret
should be ready then.
This patch moves the code for queuing CSS animation events from
nsAnimationManager to CSSAnimationPlayer. In doing so, it also moves the
mLastNotification member and associated enum values.
This patch takes the CSSAnimationPlayer object, currently defined in
dom/animation/AnimationPlayer.{cpp,h}, and moves it to
layout/style/nsAnimationManager.{cpp,h} where the rest of the CSS
Animations-specific code lives.
At the same time it extends the scope of the mozilla namespace block in
nsAnimationManager.h to also include the AnimationEventInfo and EventArray types
since these classes, which don't have an ns* prefix, probably should be in the
mozilla namespace anyway.
This patch extracts the logic for calculating animation styles from
AnimationPlayerCollection and puts the bulk of it into the Animation objects.
Some of the initial logic surrounding the animation player state (e.g. is it
paused or not, etc.) is put into AnimationPlayer.
In future we may shift this logic even further down to the AnimationEffect
objects but currently we don't create such objects unless necessary.
This patch moves code from AnimationPlayerCollection to AnimationPlayer.
However, there is one subtle change in logic involved. Previously, we would test
if the player had finished by getting the computed time of its source content
and checking if it was in the after phase or not. In this patch, however, we
simply check the play state to see if it is finished or not.
These two approaches differ in the case where an animation is paused after it
has finished. The animation phase approach will indicate the player has
finished, but the play state approach will indicate the player has paused (since
the "paused" state trumps the "finished" state). This, however, should not
produce any observable effect because when an animation is paused
mIsRunningOnCompositor will be false (we don't put paused animations on the
compositor).
This patch uses the PlayFromStyle/PauseFromStyle methods on CSSAnimationPlayer
to perform play/pause control. (This allows us to encapsulate mHoldTime and
mPaused. We will encapsulate mStartTime etc. in subsequent bugs.
The override behavior of play()/pause() with regard to animation-play-state is:
* pause()/play() override the current animation-play-state
* pause() causes the player to remain paused until play() is called regardless
of changes to animation-play-state
(* Calling play() will override the animation-play-state but won't "stick". i.e.
subsequently setting animation-play-state: paused will pause the animation.)
These different permutations are tested in the next patch in this series.
This interaction will probably become more complicated once we introduce
finishing behavior (since we might not want animations to restart when
setting animation-play-state: running).
We only need to store if an animation is paused or not, hence a bool is
sufficient. Furthermore, the convenience of using the same type as the specified
style of animation-play-state will disappear once pausing behavior is wrapped up
behind Play() and Pause() methods.
We use new_div, check_events etc. in a number of animation-related mochitests
and with this bug we'll want to use them in a few more. This patch factors them
out into animation_utils.js and tidies them up a little.
