Instead of grabbing attributes off options at every call site, pass
in the options object to processLeakLog, and attempt to get the attributes
there. If not present, use a restrictive default value.
This will prevent silent harness failures if one of the many ways to invoke
processLeakLog fails to set up these options, and makes it so they
don't have to set it up if they don't care.
Bug 931668 added the eRestyle_ForceDescendants case for all cases that
go through RebuildAllStyleData, but there is another case that calls
DoRebuildAllStyleData directly, and we should cover that too.
This is needed because when we're rebuilding the rule tree, we need to
create new style contexts for all frames.
I don't know of any bugs caused by this, but it seems worth fixing.
This is just moving one bit of data from the pres context without any
logic change. But given the other refactoring, it seems to make more
sense here now.
Within the context of determining of a layer is active, we should only consider
an element animated if it has an animation that is yet to finish, i.e. a current
animation. Animations that have finished should not cause a layer to be active
(even if they are applying a forwards fill).
This patch makes that change by calling
nsLayoutUtils::HasCurrentAnimationsForProperty instead of
nsLayoutUtils::HasAnimations.
This patch adds a method to nsLayoutUtils, alongside the existing
HasCurrentAnimations, that returns true if there exists an unfinished animation
on the element for the specified property.
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.
We can no longer call FontFaceSet::DestroyUserFontSet (what used to be
nsUserFontSet::Destroy) in nsPresContext::FlushUserFontSet, since we
need to keep tracking FontFace objects even if the list of @font-face
rules is empty.
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.
This doesn't seem to be necessary and doesn't really make sense to me. This
will help us moving region clipping into Moz2D
--HG--
extra : rebase_source : 4a5987ce2a95eaba44a69233d1b7f461f5ec16ea
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.
