We skipped updating the rule nodes for visited rules during animation-only restyle.
However, this causes isseus that visited style overrides animation styles on visited element.
So, it turns out that we should update the visited rules even during animation-only restyle.
Gecko bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1381235
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).
Before this refactoring, getComputedStyle could have side effects, and left the
style data in the element, so we could never arrive there without data.
There are a few crashtests that caught this, but this was already broken if you
called animate() on an element deep in a display: none subtree.
MozReview-Commit-ID: 1AvOvhAyOP3
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
When a transition update is needed during restyling, `get_after_change_style` is
called to re-cascade without transition rules, and this style is then used for
primary styling instead of the style just computed.
`get_after_change_style` used to ignore visited styles, so this meant that if a
transition update was needed, visited styles were effectively dropped.
To fix the crash here, we pass through the existing visited styles when
re-cascading as part of `get_after_change_style`.
MozReview-Commit-ID: 4HBQAdeJ38B
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
Right now when calling getComputedStyle with an element from another document,
we return the style using the pres context of that document, not of the document
of the window getComputedStyle was called on, so this holds.
But it will stop holding if we ever change this, so assert it doesn't happen.
Bug: 1374062
Reviewed-By: Manishearth
MozReview-Commit-ID: 3g8yQWWdsen
Before this commit, we assumed that if the element had no parent element, it was
the root of the document, which is plain false, since we can arrive there from,
let's say, getComputedStyle on a detached node.
Bug: 1374062
Reviewed-By: heycam
MozReview-Commit-ID: 65DxdzXgd0J
Otherwise, tests like the following fail, given we always match as unvisited,
and we'd never mark the link as needing invalidation.
<!doctype html>
<style>
a {
color: red !important;
}
.foo :visited {
color: green !important;
}
</style>
<div>
<a href="https://google.es">visit me</a>
<button onclick="this.parentNode.className = 'foo'">Then click me</button>
</div>
Bug: 1368240
MozReview-Commit-ID: LDv6S28c4ju
This commit also removes the old restyle_hints module and splits it into
multiple modules under components/style/invalidation/element/.
The basic approach is to walk down the tree using compound selectors as needed,
in order to do as little selector-matching as possible.
Bug: 1368240
MozReview-Commit-ID: 2YO8fKFygZI
This patch renames TNode::parent_element to traversal_parent, since it returns
the parent from the perspective of traversal (which in Gecko uses the
flattened tree). It also renames TNode::children to traversal_children
for the saem reason.
We keep parent_element and children functions on TNode to use for selector
matching, which must be done on the real DOM tree structure.
We can have cousins in the cache whose parent doesn't match ours, and other
cousins whose parent does. When we encounter one of the former, that's not a
reason to stop lookin for the latter.
Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=1369620
