The long-term plan is to drop the mozilla::css namespace altogether. Before we
go to much further with refactoring code in AnimationCommon, we should drop
usage of the mozilla::css namespace. Specifically, this patch moves the
CommonAnimationManager and AnimValuesStyleRule classes to the mozilla namespace.
This is because patch 4 now uses AddAndRemoveTransform hints for changes
that are other than adding and removing a transform. There's still a
little bit of transform-related stuff there too (which I did make
conditional in patch 2).
--HG--
extra : commitid : DF2FByhoo7E
Note that this now uses AddAndRemoveTransform hints for changes that are
other than adding and removing a transform. Since there's still a
little bit of transform-related stuff there too (which I did make
conditional), I figure it's probably best to leave the name as-is,
although I'd be open to renaming it as well.
As expected, without the patch, the filter and perspective tests fail,
but the added transform test passes. All the tests pass locally with
the patch.
--HG--
extra : commitid : 3ZfnPHG701V
Bug 960465 (specifically part 6, changeset 7d16f2fd8329) changed the way we
process animation-only style changes. This caused us to update SMIL animations
more often than is needed.
This patch adjusts this behavior to update the style from SMIL animations less
frequently by tracking when animated values have been composited without adding
the corresponding changes to a restyle tracker.
The long-term plan is to drop the mozilla::css namespace altogether. Before we
go to much further with refactoring code in AnimationCommon, we should drop
usage of the mozilla::css namespace. Specifically, this patch moves the
CommonAnimationManager and AnimValuesStyleRule classes to the mozilla namespace.
I'm fed up with having to use the NS_*Hint functions, and I also have
trouble reading/writing some of them since I don't remember the order of
parameters.
(At some point I think we should convert existing callers, but I don't
plan to do that here.)
Also renames IsPositioned to IsAbsPosContainingBlock.
--HG--
extra : rebase_source : b412f6291d34e30e8d57e054645bd1e04f43593f
extra : histedit_source : 01a2bd57de4eec4ecf3f3712ee609d70ca14cda4
It is not correct to stop restyling by leaving the old style context on
the frame and returning eRestyleResult_Stop when TryStartingTransition
provides a new, without-animations style context. This is at least
because the new new style context could have different styles from the
old new style context.
The test fails without the patch (missing underline on "an underline")
and passes with the patch (where the underline is present, and aligned
with the non-displaced text).
I confirmed that we're actually using this codepath by manually testing
<input type=color>: it works with the patch, but if I comment out the
call to nsHTMLCSSStyleSheet::PseudoElementRulesMatching from
nsStyleSet::RuleNodeWithReplacement, then the color swatch breaks, which
proves that we're depending on the code.
I think I included this in the queue because it is needed for patch 22,
although I've forgotten the full reasoning.
Note that this means that when we start transitions, we post restyles
that are processed during the current restyling operation, rather than
in a later phase. This depends on patch 11, which makes the transition
manager skip style changes that it posts while starting transitions, to
ensure that this doesn't lead to an infinite loop. This also depends on
patch 16, which only consumes restyle data for the primary frame, to
ensure that the animation restyles posted are processed properly. It
also depends on patch 14, which makes us retain data on finished
transitions, to avoid triggering extra transitions on descendants when
both an ancestor and a descendant transition an inherited property, and
the descendant does so faster.
This fixes a known failure in layout/style/test/test_animations.html and
test_animations_omta.html (as visible in the patch). I believe this is
because this patch changes us to compute keyframe values for animations
on top of a style context *with* animation data rather than one without,
which means what we're computing them on top of changes each time. (The
purpose of patch 3 was to avoid this in the case where avoiding it
matters, i.e., implicit 0% and 100% keyframes.)
This is needed for patch 17, which removes restyling phases, so that
when the transition manager posts a restyle to undo the covering done by
the cover rule, that restyle doesn't get consumed by an inner frame.
This is needed to prevent these reftests from failing:
layout/reftests/svg/smil/smil-transitions-interaction-1a.svg
layout/reftests/svg/smil/smil-transitions-interaction-1b.svg
layout/reftests/svg/smil/smil-transitions-interaction-2a.svg
layout/reftests/svg/smil/smil-transitions-interaction-2b.svg
layout/reftests/svg/smil/smil-transitions-interaction-4a.svg
layout/reftests/svg/smil/smil-transitions-interaction-4b.svg
The mIsCSS path fixes the a tests, and the !mIsCSS path fixes the b tests.
This is because this patch series changes the way in which transitions
interact with other types of animations to depend on those animations
being flushed in the animation-only style flush. (The relevant call is
added in patch 6, though we don't really depend on it until patch 17.)
This depends on bug 1087536 patch 3, which posts animation restyles
using the eRestyle_CSSTransitions and eRestyle_CSSAnimations hints.
This is used by patch 6.
This makes UpdateOverflow hint handling (which definitely did previously
need CHILDREN_AND_PARENT_CHANGED) and handling of related hints (which I
believe never actually needed CHILDREN_AND_PARENT_CHANGED) use the
CHILDREN_CHANGED hint in the overflow changed tracker, since use of
CHILDREN_AND_PARENT_CHANGED is no longer needed following the
introduction of the UpdateParentOverflow hint in patch 2.
This cleans up after bug 984226, which introduced
CHILDREN_AND_PARENT_CHANGED to deal with the facts that:
(1) most properties whose changes yield UpdateOverflow style hints
imply that an element's overflow area may have changed, and
propagation to ancestors can stop without updating the element's
parent if the element's own overflow area didn't change.
(2) a few properties whose changes yield UpdateOverflow style hints
actually don't change the overflow area of the element on which the
property changed, but instead change that element's overflow area
on the element's parent.
Having two separate hints means that we don't have to do the extra work
of always updating the parent's overflow area (when the child's overflow
area didn't actually change) for the properties in category (1), and we
don't have to do extra work of updating the element's own overflow area
for properties in category (2).
I don't have any tests that exercise this code, and I can't even find a
codepath that demonstrates that it's needed, since the lazy
reconstruction that happens during style-triggered frame reconstruction
all appears to go through PostRestyleEvent rather than
MaybeConstructLazily.
But I think we should either do this or add an assertion that it's not
needed, and given that it's one line, it seems like we may as well just
do it. (Note also that we're currently calling CreateNeededFrames at
the start of style reresolution, in
RestyleManager::ProcessPendingRestyles; this adds a call at the end.)
This makes the ReframingStyleContexts live across the lifetime of the
processing of a full queue of posted restyles.
This depends on bug 1115812 to behave sensibly (and not assert) when
rebuilding the rule tree (RebuildAllStyleData, etc.).
This handles the form of lazy frame construction that is done in
nsCSSFrameConstructor::RecreateFramesForContent, which posts a restyle.
Patch 7 handles any use of the lazy frame construction mechanism.
This patch (with patches 4 and 5 under it, but without patches 1-3)
fixes the original testcase in bug 1110277, except for some flashing of
the final position as the transition starts.
Also fixes bug 1111451.
These assertions are as requested in comment 30 in the bug.
(If the first one doesn't fire, it's possible we could even get rid of
the handling of mDoRebuildAllStyleData that it's within.)
If we discover that we've set mDoRebuildAllStyleData in the middle of
ProcessPendingRestyles(), now that ProcessPendingRestyles() fully
handles mDoRebuildAllStyleData, we only need to make a recursive call to
ProcessPendingRestyles, rather than calling RebuildAllStyleData to call
ProcessPendingRestyles.
This fixes another pre-existing bug in the rebuild-all codepath; it
didn't handle the animation-only update correctly, which could have
caused bugs in transitions with OMT animations enabled.
This means that instead of recurring into DoRebuildAllStyleData, we'll
call StartRebuildAllStyleData in the middle of processing the restyle
queue (which is fine). StartRebuildAllStyleData will move the old rule
tree out of the way and immediately do a full-tree restyle, before
returning to any queue processing that might be left (the full-tree
restyle should have consumed all remaining restyle hints, but might have
posted some new ones for handling reframes that require reframing
ancestors). And, more importantly, the EndReconstruct() call to get rid
of the old rule tree won't happen until after we're done processing the
containing RestyleTracker's queue of restyles, which reduces the risk of
having dangling old style contexts and makes it easier (in bug 1110277)
to have a ReframingStyleContexts with the right lifetime.
This changes what was probably a silly design choice when I wrote the
code for 'rem'-basis handling; we shouldn't try continuing through the
rest of RestyleElement() here, but instead repost the hint to the
rebuild-all process.
This switches RebuildAllStyleData() to the normal
ProcessPendingRestyles() manner of restyle processing. This means a
rebuild-all going through this codepath (the main rebuild-all codepath)
only sets up for non-animation restyle processing once rather than doing
it twice (and potentially having reframes posted in
DoRebuildAllStyleData() that don't get processed until
ProcessPendingRestyles(), which causes a variant of bug 1110277 with
transitions on reframed elements failing to start because it doesn't
match the lifetime of the ReframingStyleContexts).
In the new way of doing a rebuild-all, StartRebuildAllStyleData might be
called directly from ProcessPendingRestyles rather than from
RebuildAllStyleData (which null-checks the root frame) or from within
processing restyles (which can only happen when there's a root frame).
This means it needs its own null-check of the root frame.
Here we call StartRebuildAllStyleData from BeginProcessingRestyles (much
like patch 9 and EndProcessingRestyles). But we will later also call it
from the code that handles a root element font size change when we have
'rem' units. That's because it's fine to *start* the rebuild process in
the middle of processing the queue of pending restyles. (We have to end
after the whole process is done, though, in order to avoid wanting to
destroy the old rule tree while we still have style contexts referencing
it.)
We only call StartRebuildAllStyleData in this case when we're processing
our primary restyle queue (mPendingRestyles), not the animation restyles
(to be removed in bug 960465) or the animation-only restyles, since a
rebuild-all should be processed (in terms of animation phases, or in
terms of having an animation-only update before it) like a normal
restyle. (This isn't true for the 'rem' unit restyle, which could
happen during any sort of update.)
This moves the code that finishes the rebuild-all process into
EndProcessingRestyles(), which is part of the main restyling codepath.
Patch 7 ensures that we'll always get to EndProcessingRestyles in this
case, when we're going through the normal ProcessPendingRestyles()
codepath rather than the special DoRebuildAllStyleData() codepath (which
will be removed later in this patch series).
This fixes one of the omissions in the rebuild-all codepaths (where it
incorrectly differs from the regular ProcessPendingRestyles codepath).
Note that the explicit FlushOverflowChangedTracker() is no longer needed
because that's part of EndProcessingRestyles.
(This will all get refactored more substantially in the following
patches.)
This adds a member variable that is currently only used within a single
function, but that function will be split apart so that different parts
of it can be called from different places within ProcessPendingRestyles.
This is the variable that says we *need to* rebuild style data. Since
the next patch will introduce a variable that says we're *currently*
rebuilding all style data, renaming this one makes things clearer.
Part of this refactoring involves the ability to start the rebuild-all
process within the processing of restyles. This means we can't pass
parameters directly from RebuildAllStyleData into DoRebuildAllStyleData.
So this continues storing the hints as member variables a little bit
deeper into the process.
(I tried to move in a different direction in this patch queue, and store
these hints in mPendingRestyles, for the root element. But that broke
layout/style/test/test_counter_style.html and
layout/style/test/test_font_loading_api.html, and I didn't want to
figure out why. It would be somewhat better in the long run, since
currently these hints will get processed if we do a rebuild-all on a
RestyleTracker other than mPendingRestyles, which can happen if we have
'rem' units and have a root element font size change in the
animation-only update or in mPendingAnimationRestyles.)
The patches in this series refactor the process of rebuilding all style
data (RestyleManager::RebuildAllStyleData and
RestyleManager::DoRebuildAllStyleData) so that the process of rebuilding
all style data uses the existing restyle processing loops in
ProcessPendingRestyles. (Rebuilding all style data is what we do when
we need to throw away the rule tree because something has invalidated
the cached data in it.) This removes (increasing, especially with bug
960465 coming) code duplicated between the two codepaths, fixes some
omissions from the separate rebuild-all codepath, and (more immediately)
allows fixing lifetime issues of ReframingStyleContexts objects in bug
1110277 so that we can have a single ReframingStyleContexts for all of
the restyle processing in each restyle processing operation. In other
words, the goal is to change the rebuild-all process from a separate
codepath to a few variables that modify the way ProcessPendingRestyles
works (and make it do the extra work).
This is just a small first step in that process, which moves one piece
of code from a chunk of duplicated and to-be-removed code into a chunk
of code that will be preserved.
This patch is not needed to fix the bug, but it seems like it's probably
desirable. It's not needed for this bug because
MaybeReframeForBeforePseudo and MaybeReframeForAfterPseudo are already
called (by ElementRestyler::RestyleChildren) on only the first and last
continuation or ib-split sibling with the same style. So this patch
should only actually change anything for cases like a block-in-inline
split whose initial inline part is inside of a ::first-line (where
different parts of the block-in-inline split chain have different style).
Since the symptom of this bug is (once patch 6 is in the tree) only
causing extra reframes, it can only be tested using the new API (from
bug 1115691) for observing reframes. I confirmed that the test for this
bug fails without the patch and passes with the patch (as noted by the
removal of its todo annotation).
For some kinds of changes we need to update the layer tree even though there is
no change to style. For example, if an animation is paused via the Web
Animations API, we need to remove the animation from the layer even though the
style will not change.
This patch detects such changes by making ElementRestyler check for an
out-of-date animation generation on layers. This is complicated by the fact that
we currently maintain *two* animation generation numbers: one for the set of
animations and one for the set of transitions, but we only have *one* animation
generation number on each layer. This is a known issue (bug 847286).
As a result, until bug 847286 is fixed, we need to be careful to compare against
the greater of the two numbers.
Until we get rid of animation phases in bug 960465, we need to ensure
we're producing style data for the correct animation phase. This makes
this optimization slightly less beneficial until then.
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.
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.
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 needed because patch 1 and patch 3 did not add a mechanism that
allows restyling pseudo-elements, which would be substantially more work
and very little use (since the only case in which they have style
attributes is for our internal use on the ::-moz-color-swatch
pseudo-element).
RestyleUndisplayedChildren does not need the same fix because it's only
used on elements, and never on pseudo-elements or anonymous boxes.
We don't do struct swapping if either the old or new style contexts are
shared, since we can't guarantee that such a change will be valid for
all frames that use the shared style context.
--HG--
extra : rebase_source : 10f7c90422de23b119287ba478d36433423440da
