We use RestyleManager::mAnimationGeneration as the animation index of a
new created transition, and Element.getAnimations() uses this index to
sort the order of transitions. We increase mAnimationGeneration one per
restyle cycle if there is any non-animation update.
MozReview-Commit-ID: KmirBzI7CXi
This also removes the TABLE_ATTRS_DIRTY optimization. Constructing nsMappedAttributes isn't really expensive and we do it all the time anyway.
MozReview-Commit-ID: 2krt1nFUzgl
This patch exists to avoid a crash in layout/style/test/test_animations.html. We end up
generating some ::before content, which causes us to style the new subtree at [1]. In
StyleNewSubtree, we fail the !postTraversalRequired assertion because
PrepareAndTraverseSubtree decided to traverse the tree twice (once to style it, and again
to restyle it for animations), and return that a post-traversal is needed.
The reason this issue happens with my NAC patches and not without is that we were previously
filtering out generated ::before content from the servo traversal, so the servo traversal
wouldn't have reached it and (presumably) the animation restyle wouldn't have happened and
we wouldn't have returned true for needing a post-traversal.
[1] http://searchfox.org/mozilla-central/rev/c48398abd9f0f074c69f2223260939e30e8f99a8/layout/base/nsCSSFrameConstructor.cpp#1918
MozReview-Commit-ID: 8tgzLjV8B3A
The Gecko restyle manager does this synchronously, along with a content flush.
In my testing there's no need to do so, and Boris couldn't think off-hand of
why, except the fact that we have this mRebuildAllStyleData thing that takes
care of rebuilding the rule tree, which is quite sensitive.
Also, Boris made a good point about non-inheriting anon boxes, that could
technically change style. I've left a note about it too.
MozReview-Commit-ID: 2lvzhxugKB0
The restyle request during restyling is a result of creating/updating/removing
CSS animations that will come from a SequentialTask which will be implemented
in a subsequent patch.
MozReview-Commit-ID: JoAqvcN3y51
For the reasoning for this change, please see the related bugs and:
http://logs.glob.uno/?c=mozilla%23layout&s=22+Feb+2017&e=22+Feb+2017#c27236
Mainly, before this change, there was nothing forcing style structs computed in
a style context to remain computed for the new style context after a call to
CalcStyleDifference. This can make us skip change hints when a style change
doesn't force to recompute one of these structs.
MozReview-Commit-ID: FoWbLjt97Uu
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
For a table, the primary frame is the table wrapper anonymous box. That
anonymous box inherits style from its _child_ table frame, which is the frame that
has the actual style for the element. So we want to use the stylo-computed
style for the table frame, and then compute an updated style for the table
wrapper too, because some things (like absolute positioning) are done for the
table wrapper anonymous box, not the table frame.
If there are pending restyles, and we were called with zero change and restyle
hints, then we're still not going to do any extra work. So we may as
well return early after only checking the hints.
MozReview-Commit-ID: ACCGtDZcOJ0
When any explicit change hint appears to trigger, for example, a repaint, this
assertion is no longer true, and we should indeed avoid recreating the style
context unnecessarily for that element.
MozReview-Commit-ID: Ln7lBPZW0kp
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
1. Add one new FFI, Gecko_GetAnimationRule, which will try
to update the animation rule and retrieve a ServoAnimationRule
from EffectSet.
2. Add GetServoAnimationRule, which calls Animation::ComposeStyle and updates
mElementsToRestyle.
3. There is no eRestyle_{CSSAnimations|CSSTransitions}, so we use
eRestyle_Self and eRestyle_Subtree for stylo.
MozReview-Commit-ID: 9RpJurPSFMk
The setup is quite different to Servo-land, so add a comment about the different
setup.
Also, check viewport rules when flushing stylesheets. I believe that the
previous behavior is plain wrong, though I haven't taken the time to come up
with a test case.
In any case, it doesn't hurt any of both back-ends.
MozReview-Commit-ID: 46gtTkesOsr
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
Since we use the presence of a change hint to determine whether we should
recreate a style context, we can't just strip them out on CalcStyleDifference.
MozReview-Commit-ID: GLhbTc2W3d7
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
