Create an extra style context using the visited values (if they exist). This
mirrors the logic Gecko performs in nsStyleSet::GetContext for visited support.
MozReview-Commit-ID: EiJQXDgz8tX
Create an extra style context using the visited values (if they exist). This
mirrors the logic Gecko performs in nsStyleSet::GetContext for visited support.
MozReview-Commit-ID: EiJQXDgz8tX
Also, add GetParentAllowServo() to whitelist the usage in servo-backed style
system in subsequent parts so that we could revisit them later.
MozReview-Commit-ID: JthU18Ftx02
--HG--
extra : rebase_source : b8840adcc4959f96cd429db65584f3e83c09c597
nsStyleContext::CalcDifference had an optimization where, when we knew
that the old and new style context have the same rule node, we knew that
the only change hints that would need to be handled are those in the
"not handled for descendants" category, generated due to explicit
'inherit' values on reset properties. This was because any changes due
to differences in inherited properties should only have generated
"handled for descendants" change hints (and thus would already have been
handled on an ancestor).
Before bug 931668, this let us avoid calling CalcDifference on structs
that only would have generated hints that we knew we already would have
handled. However, after bug 931668, we compare all structs anyway so
that we can set the aEqualStructs outparam, so we don't gain anything
from this optimization. We can still return these change hints we know
will not need to be handled, and rely on ElementRestyler::CaptureChange
to filter them out.
MozReview-Commit-ID: Ld1s2Js0i6r
We also assert against the Servo traversal because we don't currently test the
parallel traversal on CI (though we will soon).
MozReview-Commit-ID: 9GRNizE44Oi
The idea is to be able to call the right function during style resolution time
without doing a linear walk via nsCSSAnonBoxes::IsNonInheritingAnonBox.
MozReview-Commit-ID: JKt33GggTjz
--HG--
extra : rebase_source : fcf477dcef8529c803bf97b1d3a16f8f4fcea39f
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>
--HG--
extra : rebase_source : 27772fc67b3c241ca4cef580112c949ad506b167
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>
I think there are three advantages of this change:
1. removes some dependencies from layout / painting code to pre-computed
value stuff in the style system;
2. makes it easier to audit usage of specific fields in style structs
(which is probably a side effect of the first one);
3. potentially improves performance since it doesn't go through the
unnecessary general logic in ExtractComputedValue.
Also, combined with the part before, we get a unified list for visited-
dependent properties so that we can ensure the assertion here and the
style difference calc code are consistent.
MozReview-Commit-ID: 5B9aN7CfRgI
--HG--
extra : rebase_source : ac80eaea2474b9ec4b47b1cc9a5bdd2e61f6ec4d
This change avoids lots of false positives for Coverity's CHECKED_RETURN
warning, caused by NS_WARN_IF's current use in both statement-style and
expression-style.
In the case where the code within the NS_WARN_IF has side-effects, I made the
following change.
> NS_WARN_IF(NS_FAILED(FunctionWithSideEffects()));
> -->
> Unused << NS_WARN_IF(NS_FAILED(FunctionWithSideEffects()));
In the case where the code within the NS_WARN_IF lacks side-effects, I made the
following change.
> NS_WARN_IF(!condWithoutSideEffects);
> -->
> NS_WARNING_ASSERTION(condWithoutSideEffects, "msg");
This has two improvements.
- The condition is not evaluated in non-debug builds.
- The sense of the condition is inverted to the familiar "this condition should
be true" sense used in assertions.
A common variation on the side-effect-free case is the following.
> nsresult rv = Fn();
> NS_WARN_IF_(NS_FAILED(rv));
> -->
> DebugOnly<nsresult rv> = Fn();
> NS_WARNING_ASSERTION(NS_SUCCEEDED(rv), "Fn failed");
--HG--
extra : rebase_source : 58788245021096efa8372a9dc1d597a611d45611
It's a shame that assertion can be made a crashing one, but unfortunately it was
hitting me regularly.
MozReview-Commit-ID: 4iZf1rm1fO2
--HG--
extra : rebase_source : 0b9ef55e3036eeefe4b989c284b1aff3e99a906d
