Make the order of rules in DevTools be the specificity order.
We insert rules with any important declaration into rule tree twice,
one for the normal level and another for the important level. And
when we fetch them from rule tree, we skip the important one to
make the order be the specificity order.
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix [Bug 1391198](https://bugzilla.mozilla.org/show_bug.cgi?id=1391198)
<!-- Either: -->
- [ ] There are tests for these changes OR
- [X] These changes do not require tests because test cases already in gecko
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/18337)
<!-- Reviewable:end -->
We insert rules with any important declaration into rule tree twice,
one for normal level and another for important level. And when we fetch
them from rule tree, we skip the important one to make the order be
MozReview-Commit-ID: HewZG6jYVvv
The alias is left there temporarilly and will be removed completely in a later commit where
also components/style/gecko/generated/structs_{debug|release}.rs are re-generated (they still
use the old alias).
This is unfortunate, but for now it complicates things, I would like not needing
a ElementData to get the style of an Element in order to fix all the
getDefaultComputedStyle bugs.
MozReview-Commit-ID: LZvsdFEqrDE
Before this change, the `ComputedStyle` struct that is part of permanent style
data per element holds 2 `StrongRuleNode`s (unvisited and visited) and 2
`Arc<ComputedValues>` (unvisited and visited).
Both rule nodes and the visited values don't actually need to be here. This
patch moves these 3 to new temporary storage in `CascadeInputs` on
`CurrentElementInfo` during the match and cascade process. Rule nodes are
pushed down inside the `ComputedValues` for later access after the cascade.
(Visited values were already available there.)
The permanent style data per element now has just the `Arc<ComputedValues>` for
itself and eager pseudo-elements (plus the `RestyleHint`).
MozReview-Commit-ID: 3wq52ERMpdi
It seems that changeset 97ce9ed5b0
mistakenly changed the check that a cascade level to keep is *not* an
animation level to a check that it *is* an animation level.
To support visited styles, we match and cascade a separate set of styles any
time we notice that an element has a relevant link.
The visited rules and values are held in `ComputedStyle` alongside the
regular rules and values, which simplifies supporting various APIs like
`cascade_primary_and_pseudos` which expect easy access to previously matched
rules.
To simplify passing the additional values around, an additional reference to the
visited `ComputedValues` is placed inside the regular `ComputedValues`.
MozReview-Commit-ID: 2ebbjcfkfWf
In the case where we process an element which has SMIL animations in normal travesal
the SMIL styles must have been computed in animation-only restyles. So we
have only to pick the computed styles instead of recomputing it.
We add one FFI, Servo_GetProperties_Overriding_Animation, which calls
StrongRuleNode::get_properties_overriding_animations() to get a LonghandIdSet,
which may override animation properties running on compositor.
