To traverse pseudo elements in animation-only restyle, the pseudo element
itself needs the animation-only dirty bit.
MozReview-Commit-ID: 11RfVqnPXfJ
--HG--
extra : rebase_source : d048c9a053c03bf3fef46fcbfd9cbd5f60204e1d
As I've said before, as module owner I prefer that MOZ_ASSERT_IF not be
used in the module because I consider it to be unreadable. However, a
few uses have crept in, and this patch removes them.
I consider it to be unreadable because the name looks like a name that
uses smalltalk-ish naming conventions, i.e., with a part of the name
corresponding to each parameter, in order. However, the parameters are
in the order opposite the name.
This was written primarily with the vim commands:
:%s/MOZ_ASSERT_IF(\([^,]*\),/MOZ_ASSERT(!\1 ||/
:wn
followed by manual cleanup for indentation and removal of !!.
MozReview-Commit-ID: G6rLbOn7k8d
This can happen with content attribute or state changes that end up not
generating any hint.
In particular, in the media_queries_dynamic.html case, the iframe resize was
toggling a few scrollbar attributes, which made us never pass the "didn't
restyle" test, even though the test really passed.
I'll probably need to add a workaround to assume we use viewport units, so
probably won't pass for long.
MozReview-Commit-ID: 2oEfic5yaOy
And propagate the new flag to servo if mRestyleForCSSRuleChanges is set.
MozReview-Commit-ID: HRZ5duYgciF
--HG--
extra : rebase_source : 65528ea0dfa21e84bb9184a849c72a5c322e306b
The difference is that PostRestyleEventForCSSRuleChanges sets
mRestyleForCSSRuleChanges true. In a subsequent patch,
we propagate a new TraversalRestyleBehavior flag to servo side
if mRestyleForCSSRuleChanges is true.
MozReview-Commit-ID: IKsBbm09uT9
--HG--
extra : rebase_source : 5014c0a978f98e81543ec7766d2daa415317069c
We need to request an animation-only restyle to force flush all throttled
animations on main thread when we handle an event with coordinates
(e.g. mouse event).
MozReview-Commit-ID: KkjeQVsLgTl
--HG--
extra : rebase_source : 314408062e719e9f52df9a6726e2f3dad817bbef
Some changes to animations don't affect the computed style and yet still
require the layer to be updated. Therefore, we also need to call
AddLayerChangesForAnimation in ServoRestyleManager. In this patch, we
factor out this function from GeckoRestyleManager, so we can reuse it.
MozReview-Commit-ID: LL7D1oGS65l
--HG--
extra : rebase_source : cd028a3d8f5dc251ec6615918a0f9569f0af44f5
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
--HG--
extra : rebase_source : b02d516ea164fc567110338411bf6ba251d53dab
This also adds assertions to ensure attributes and state don't change during
layout or frame construction.
MozReview-Commit-ID: BANcpxnRsYS
--HG--
extra : rebase_source : 5d1bc424d3ed90fda3047d3c92c09251346b7bec
This also happens to fix other bugs, like making display: contents pseudos
animatable, which weren't before.
MozReview-Commit-ID: LhwTPNbFvSZ
--HG--
extra : rebase_source : 785105b08d6bfa15ad257e61b769a263c6810ad0
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
--HG--
extra : rebase_source : 6a9001ea99f86c25b1d8d0a822b51b8753248bfb
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
--HG--
extra : rebase_source : 18d400aed6f427e5efc503b87b6ee2d9af74f3f5
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
--HG--
extra : rebase_source : 38cf56811f73f5a9f0f6659e08d03e78d4c6dcb5
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
--HG--
extra : rebase_source : fdff59771b81518509dfd52e73d3f63ddb82390d
Emilio Cobos Álvarez
Manish Goregaokar
Cameron McCormack
Ryan VanderMeulen
Hiroyuki Ikezoe
L. David Baron
Boris Chiou
Ting-Yu Lin
Bobby Holley
Boris Zbarsky