- Implemented boilerplate to add the scroll-behavior CSS property.
- Added layout.css.scroll-behavior.property-enabled preference to
allow the scroll-behavior CSS property to be enabled independently
of the CSSOM-View DOM scrolling api extensions for smooth scrolling.
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.
This patch adds another method to AnimationPlayerCollection alongside
HasCurrentAnimations that returns true if there is a player in the collection
with current source content that targets the specified property.
At the same time it also makes the original HasCurrentAnimations a const method.
It's not the player that's "current" (a Web Animations term for an animation
that hasn't yet finished), but its source content, if any. This patch renames
the method on AnimationPlayer accordingly.
At the same time this patch moves the method to the header file since it's
quite simple and could possibly benefit from inlining.
This implements the bulk of the FontFace JS constructor, which parses
the descriptors passed in. We need a notion now of whether a FontFace is
"initialized", since the spec requires us to go through the event loop
before parsing the 'src' descriptor. So a couple of places now have to
check whether the FontFace is fully initialized, and we have a method to
inform the FontFaceSet when a FontFace becomes initialized, in case we
added it to the FontFaceSet before it was initialized (easy to do with
|document.fonts.add(new FontFace(...))|.
We add a third array on FontFaceSet, mOtherFaces, which stores
unconnected FontFace objects that have been added to the FontFaceSet. We
reflect them in the indexed properties and also create user font entries
for them.
Part 23 will actually allow us to add some of these FontFaces to
mOtherFaces.
This adds support for a CSS-connected FontFace to be disconnected from
its rule. This causes it to get its own copy of the descriptors on the
nsCSSFontFaceStyleDecl, and for the pointers between the FontFace and
the nsCSSFontFaceRule to be nulled out.
We start tracking now whether a given FontFace is in the FontFaceSet
(in the sense that it will appear on the DOM FontFaceSet object if we
inspect it with script). All FontFace objects created though, whether
they are currently "in" the FontFaceSet or not, are still tracked by the
FontFaceSet. We use the new mUnavailableFaces array on the FontFaceSet
for that.
We need to track these FontFaces that aren't in the FontFaceSet as
that's where we store their user font entry -- important if we call
load() on a FontFace before adding it to the FontFaceSet.
This changes InsertRule, which looked at the descriptors on an
nsCSSFontFaceRule to create a user font entry and add it to a family,
into InsertConnectedFontFace, which can do the same but for the FontFace
that reflects the rule.
Here we change FontFaceSet's records array to associate gfxUserFontEntry
pointers with FontFace pointers, rather than with nsCSSFontFaceRule
pointers. This will make it more uniform to handle both CSS-connected
and unconnected FontFace objects when rebuilding the user font entries
under UpdateRules.
How that we have a class named "FontFace", it's a bit confusing for some
of the gfxUserFontSet methods to have "FontFace" in their names, so I'm
renaming them to mention "UserFontEntry" instead.
These set the descriptors, but don't cause anything to update, just
like setting descriptors on an @font-face rule's style declaration
doesn't do anything yet.
We add an mDescriptors that will be used to store the descriptor values
of an unconnected FontFace object. For CSS-connected FontFace objects,
the descriptors are stored in the nsCSSFontFaceRule::mDecl.mDescriptors.
(Both of these use the same type, though, CSSFontFaceDescriptors.)
Ideally we could have the descriptors always stored on the FontFace,
and for the nsCSSFontFaceStyleDecl go and fetch them from the FontFace,
but it turned out to be impossible to ensure that a FontFace could be
created whenever a nsCSSFontFaceStyleDecl was cloned, since it needs
access to the window object to create the FontFace's promise objects!
We make gfxUserFontEntry::SetLoadState virtual so that we can hook into
changes and update FontFace::mStatus. We can't just reflect the
gfxUserFontEntry's value in FontFace::Status() since the spec has
requirements about when exactly the status is set.
This is a temporary measure until we support iterators on the
FontFaceSet; the spec does not expose FontFaces as indexed properties on
the FontFaceSet.
Every nsCSSFontFaceRule that is used will get a FontFace object to
reflect it in the FontFaceSet. Here we add storage on the
nsCSSFontFaceRule for its FontFace, although it will be the
FontFaceSet's responsibility to set it. We also add a static
constructor function on FontFace to create one that reflects a rule.
We can't make FontFace inherit from gfxUserFontEntry, since the former
is cycle collected. So instead, we have a small class that inherits
from it that will override its virtual methods and forward things on to
the FontFace object.
We make gfxUserFontSet::CreateFontFace virtual so we can override it to
produce instances of our gfxUserFontEntry subclass.
This (a) moves ownership of the gfxUserFontSet into FontFaceSet, (b) moves
nearly all of the functionality of nsUserFontSet into FontFaceSet, and (c)
adds a class that inherits from gfxUserFontSet so that we can override some
of its virtual functions and delegate them to the FontFaceSet.
The MOZ_DEBUG_RESTYLE_STRUCTS environment variable can be set to a comma-
separated list of style struct names. When restyle logging is enabled,
this will cause the style context tree -- showing cached style struct
pointers for those structs specified -- to be logged before each
individual restyle is processed. It will also show the struct pointer
values involved when swapping structs between style contexts.
For example, set MOZ_DEBUG_RESTYLE_STRUCTS=Font,UserInterface to show
the cached nsStyleFont and nsStyleUserInterface pointers on the style
contexts involved in the restyle process.
Set the MOZ_DEBUG_RESTYLE environment variable and every restyle will have
detailed logging printed to stderr. By default, restyles for animations are
not logged; you can include them by also setting MOZ_DEBUG_RESTYLE_ANIMATIONS.
If you wish to limit restyle logging to a particular change, you can call
nsPresContext::StartRestyleLogging() and nsPresContext::StopRestyleLogging()
at appropriate points. (You might want to add a couple of helper methods
temporarily on nsIDocument and then expose them to your page with Web IDL
to make them easier to call.) You do not need to have set MOZ_DEBUG_RESTYLE
for this to work.
This patch takes the StickyTimeDuration defined in the previous patch and
uses it within the calculation of animation timing for parameters that are
expected to be +/- Forever.
Set the MOZ_DEBUG_RESTYLE environment variable and every restyle will have
detailed logging printed to stderr. By default, restyles for animations are
not logged; you can include them by also setting MOZ_DEBUG_RESTYLE_ANIMATIONS.
If you wish to limit restyle logging to a particular change, you can call
nsPresContext::StartRestyleLogging() and nsPresContext::StopRestyleLogging()
at appropriate points. (You might want to add a couple of helper methods
temporarily on nsIDocument and then expose them to your page with Web IDL
to make them easier to call.) You do not need to have set MOZ_DEBUG_RESTYLE
for this to work.
This is an additional bit on nsRestyleHint that says that the restyling
operation should also perform all the work needed to switch between
style-without-animation and style-with-animation (based on
nsPresContext::IsProcessingAnimationStyleChange). These concepts will
go away in bug 960465.
Note that we don't want this behavior for the animation-only style
update code (bug 996796, etc.), and I wanted to make this explicit so
that it was clear when it was happening, and so that it was clear what
code should be removed when we git rid of it.
This is the workaround needed to land bug 977991 prior to bug 960465.
(I think there's also a minor dependency in the other direction, so we
need a workaround one way or the other.)
Note that this depends on bug 1057231.
This allows posting a restyle that says that only the rule(s) from the
StyleAttrSheet cascade level will be replaced, which avoids running
selector matching.
Part 4 will ensure that we only invoke this code for element styles (and
not pseudo-element or anonymous box styles). Despite that, I prefer
having the runtime check here as well given that it's a very simple way
to ensure we don't do something silly that might have security
implications.
This allows nsStyleSet::RuleNodeWithReplacement to call it without
constructing an entire (and unnecessary) ElementRuleProcessorData, which
will happen in patch 3.
This allows posting a restyle that says that only the rule(s) from the
SVGAttrAnimationSheet cascade level will be replaced, which avoids running
selector matching.
This is needed to land bug 977991 prior to landing bug 960465, since
that requires replacing all levels that contain animations.
(I'll rename this to match the name determined in bug 1057231.)
This allows nsStyleSet::RuleNodeWithReplacement to call it without
constructing an entire (and unnecessary) ElementRuleProcessorData, which
will happen in patch 2.
This is only a very slight reordering of their position in the cascade,
since they were previously walked at the end of
nsSVGElement::WalkContentStyleRules, which was called near the end of
nsHTMLStyleSheet::RulesMatching. So the only change should be that they
now take priority over the xml:lang rule added by nsHTMLStyleSheet, a
rule with which they do not interact.
I will fix the indentation of gCascadeLevels in bug 977991 patch 2,
which adds a member to each element of the array.
Note that this bumps the maximum sheetType from 8 to 9 (and number of
them from 9 to 10), which does not require updating
NS_RULE_NODE_LEVEL_MASK, since NS_RULE_NODE_LEVEL_MASK currently has 4
bits and allows a maximum of 15.
This patch series (to move SVG Animation rules to their own level of the
cascade) is needed so that they can participate in the mechanism for
updating only animation styles to the present time without touching any
other styles.
In theory, this should have been done as part of 996796 or even as part
of prior work on off main thread animations, except that it doesn't seem
possible to have SVG Animations and CSS Transitions interacting on the
same element and have that element's style out of date, which means it
wasn't necessary for the existing code to update only animation styles.
However, bug 960465 will use this similar mechanism as the new mechanism
for making sure transitions start in a reasonable way (replacing the
mechanism of phases, going from style without animation to style with
animation via nsPresContext::IsProcessingAnimationStyleChange). This
will require that, for SVG Animations to continue interacting correctly
with CSS Transitions, that they have their own cascade level so that
they can participate in RestyleManager::UpdateOnlyAnimationStyles.
Additionally, this is needed even sooner, for bug 977991, which needs
(temporarily, until bug 960465 lands) a mechanism for updating the style
attribute style *and* all animation-phase-dependent styles.
Yes, it's a little bit annoying to have to have another class, and
another object per-document for this, but that's currently what comes
with being a level of the cascade. But it's one class and one object
per document, and I believe there will be substantial benefits to having
all rule processor levels be only-animation-related or
not-animation-related (except for the style attribute level, which is
simple enough that it isn't needed yet).
This is fine since the assertion is just checking that we're not calling
RuleNodeWithReplacement in cases when stronger restyling (i.e.,
restyling that does more work) is needed; the new eRestyle_Force and
eRestyle_ForceDescendants flags control whether we restyle at all.
This probably should have been done in bug 931668 (since bug 996796
landed before bug 931668, although not before the patches were written),
but it doesn't actually show up in our test suite until bug 977991 (or
maybe slightly earlier in bug 1057231 or bug 1058346).
