Delete the NS_WARNING because it's not needed once this bug is fixed.
MozReview-Commit-ID: Ht3ayjSvYW8
--HG--
extra : rebase_source : 457f011ac64fcd511ec2f15ea2b8ce24a88b0d84
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
If a frame doesn't have that bit then skip mCounterManager.DestroyNodesFor()
when the frame is destroyed because it's definitely not known by
the CounterManager.
MozReview-Commit-ID: Ky3575QvZME
When the counter style in the style struct changes, CalcDifference
would return ReconstructFrame, which should cause corresponding use
node to be reconstructed. That means a use node with retired counter
style should always be destroyed in the next flush, so it makes no
sense to reset them anymore.
However, we would still need to mark counter lists dirty because
otherwise their content may not get update when there are changes to
counter styles which are still valid.
MozReview-Commit-ID: FnBPx81StzG
--HG--
extra : rebase_source : 2adf7b64484746a5f416b7902df2ac718a3fdeab
And propagate the new flag to servo if mRestyleForCSSRuleChanges is set.
MozReview-Commit-ID: HRZ5duYgciF
--HG--
extra : rebase_source : 65528ea0dfa21e84bb9184a849c72a5c322e306b
Also, assert that this presContext is non-null (which we already implicitly
assume, when we dereference it without null-checking it).
MozReview-Commit-ID: IIYUqGQTOnb
--HG--
extra : rebase_source : 67cbf91fb2fdeb46352559fb519693d6d13d3224
Also, assert that this presContext is non-null (which we already implicitly
assume, when we dereference it without null-checking it).
MozReview-Commit-ID: IIYUqGQTOnb
--HG--
extra : rebase_source : 67cbf91fb2fdeb46352559fb519693d6d13d3224
This avoids conflicts with mozilla::dom::FrameType.
MozReview-Commit-ID: 7aEMbHRaTFk
--HG--
extra : rebase_source : 2d01321f5ce0ec8c0e3f70984674f82678034b3c
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
Probably GetAnimationCollection itself should assert against it, but that's a
bigger task right now...
MozReview-Commit-ID: JxFWXtgMAXy
--HG--
extra : rebase_source : 90ffd33e56dd8d285765bc7a06572b0ae229b5e7
If we append children to an element inside a display:none tree and we
decide not to do lazy frame construction, StyleNewChildren will assert.
It's also unnecessary, anyway, since we want to keep the descendants
of the display:none element free of ElementData.
MozReview-Commit-ID: 19tuzAzAIDp
--HG--
extra : rebase_source : 457a2c037a02ff50647eed84f51cbee29f737ecd
It wasn't clear to me whether the existing check for whether we are
under a restyle was sufficient to cover all cases of reconstructing
frames, so this patch makes it more explicit by passing that state
into ContentAppended and ContentRangeInserted.
MozReview-Commit-ID: HjlDCzJv97n
--HG--
extra : rebase_source : 8ce4ba097f706e3d9a1f1292515dca64fb8765ab
Note that this removes the useless (because this anon box is never absolutely
positioned) "clip: inherit" style.
MozReview-Commit-ID: iJJdv5VL06
--HG--
extra : rebase_source : d7a8697a89391eb6a80683dcbe8e3fa6f76c6a41
::first-letter is not support by stylo yet. (bug 1324618)
MozReview-Commit-ID: KwQk2jhn53c
--HG--
extra : rebase_source : 9bafad53a38fd11aae7be09780ee7680d9a40e1c
