Invalidating a relative selector requires traversal in the opposite direction of
the usual invalidation, i.e. In the directions of ancestor and/or earlier sibling.
However, when there are complex selectors within the relative selector, e.g.
`:has(:is(..) ..)`, we first need to perform invalidation in the usual direction to
reach the relative selector's search space, then perform the relative selector
invalidation.
There are two major changes to this effect:
1. `InvalidationProcessor` has an additional lifetime that separates matching context from
invalidations. This enables storing encountered dependencies (Since we may be in a deep recursion
during the invalidation) to be relative selector invalidated, without requiring that the
matching context live that long.
2. There now exists a separate category for relative selector invalidation depenedencies,
which triggers relative selector invalidation. Dependencies now can be either normal or
relative, since any complex selector inside a relative selector would have normal
dependencies, but with its outer dependency being a relative dependency.
Differential Revision: https://phabricator.services.mozilla.com/D185675
To increase the integration between color and calc it is nescessary to
vendor the current cssparser-color library into Gecko where all the calc
functionality lives.
Differential Revision: https://phabricator.services.mozilla.com/D188216
The root cause here is that percentages when mixed with lengths don't
compare / simplify, because the basis might be negative (bug 1709018),
so PartialOrd returns None for them.
When parsing a plain percentage / resolving to a percentage however, we
do want them to resolve. The regressing bug broke that because min > max
etc would effectively return false.
Differential Revision: https://phabricator.services.mozilla.com/D187974
When the progress is 100%, the result from the original formula of calculating
`left_weight` may not be 0 exactly (i.e. approximate zero, e.g. -2.22e-16), and
so this imprecision makes the recomposed Matrix3D have some approximate zeros.
Those approximate zeros (e.g. `_m13` is 2e-16, and `_m23` is 8e-17 in WPT)
make us failed to treat this Matrix3D as a 2D matrix when we serializing it
(because we use `!= 0.0f` to check if the matrix components are not equal to
zero in `Matrix4x4::Is2D()`, and other places).
Differential Revision: https://phabricator.services.mozilla.com/D187814
This undoes bug 1835681, adjusting for changes that happened since then,
because the crates don't build with the real bitflags 2, and there are
some challenges to make them work with the real bitflags 2.
Differential Revision: https://phabricator.services.mozilla.com/D187748
Computed value-time validation for fallback values is added in a later
patch.
Bug 1852360 is opened for computed value-time validation for properties
that contain references.
Differential Revision: https://phabricator.services.mozilla.com/D186997
Basically, if two normalized direction vectors are the same, we do
interpolation on the angle only. However, after normalization, there may
be some differences because of the floating-point precision, even though
these two vectors have the same direction. Therefore we have to add an
tolerance when comparing them.
Differential Revision: https://phabricator.services.mozilla.com/D187153
The implementation is uglier than it needs to be. We basically need to
override the GTK styles for the window decorations with the desired
radius.
This is because of two reasons:
* Adwaita on gtk3 doesn't provide a bottom corner radius.
* Even if it did we couldn't reasonably query it, see comment 4.
So in order for stuff to look sensible we need to make sure that we and
GTK agree on what radius to use. Using the titlebar radius makes sense
here.
Differential Revision: https://phabricator.services.mozilla.com/D187343
This avoids uselessly rewinding the parser for single-keyword display
values, and generally makes the code easier to follow.
Differential Revision: https://phabricator.services.mozilla.com/D187431
Basically, quaternion vectors make sense only when the rotation is within
(-360deg, 360deg). If its angle is larger than or equal to 360deg, its
direction may be different, so we have to tweak the conversion.
Also, tweak the code of interpolation for rotate3D to match the spec and
put more comments there.
Differential Revision: https://phabricator.services.mozilla.com/D186998
We keep these functions because we used them for compositor animations before
merging stylo. Now we always use the equivalent rust version for all the
transform interpolation, on both the main thread and the compositor thread.
Differential Revision: https://phabricator.services.mozilla.com/D187072
This fixes the incorrect result when negating a clamp() where the min value is greater than max.
Added some extra tests to clamp-length-computed.html; the last example fails in Gecko without
the patch here.
Differential Revision: https://phabricator.services.mozilla.com/D187113
This is not standard, and we don't use it internally (some chrome
stylesheets use it tho).
In the past this pseudo-class was more useful because it matched the
state for which <img> elements used an inline, but that's no longer
true, see bug 1196668 and co.
Depends on D186938
Differential Revision: https://phabricator.services.mozilla.com/D186939
This is technically web-exposed, but if we needed to introduce it for
compat we could always re-introduce it matching false.
Differential Revision: https://phabricator.services.mozilla.com/D186938
The old code was basically doing string copies that are totally
redundant, in a not-very performant way too.
This was from the time where stylo had to live with the old style
engine, and there's no need to keep the copy around anymore.
Differential Revision: https://phabricator.services.mozilla.com/D186974
This is technically web-exposed, but if we needed to introduce it for
compat we could always re-introduce it matching false.
Differential Revision: https://phabricator.services.mozilla.com/D186938
