I've chosen this approach mainly because there's no other good way to guarantee
the model is correct than holding the snapshots alive until a style refresh.
What I tried before this (storing them in a sort of "immutable element data") is
a pain, since we call into style from the frame constructor and other content
notifications, which makes keeping track of which snapshots should be cleared an
which shouldn't an insane task.
Ideally we'd have a single entry-point for style, but that's not the case right
now, and changing that requires pretty non-trivial changes to the frame
constructor.
MozReview-Commit-ID: FF1KWZv2iBM
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>
