- Updated smooth scroll behavior mochitest and reftests to
match new CSSOM-View DOM scrolling method parameters.
- Added tests for Element.ScrollBy and Element.ScrollTo.
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).
