Note that although this builds, it would (by itself) result in some test breakage;
this is resolved in the following patches that build on this.
Differential Revision: https://phabricator.services.mozilla.com/D198790
Note that although this builds, it would (by itself) result in some test breakage;
this is resolved in the following patches that build on this.
Differential Revision: https://phabricator.services.mozilla.com/D198790
Resolution of such custom properties (And other properties depending on them)
must take place after font-related properties (Which are prioritary) are
resolved. Resolution of custom properties is therefore split into two phases,
before and after prioritary properties are resolved.
Differential Revision: https://phabricator.services.mozilla.com/D196195
Registered custom properties may utilize font-relative units such as `em`,
`ex`, etc. Font-related properties (More with `calc()` unit algebra), in
turn, may refer to such registered custom properties, leading to a cycle
(Note, unregistered properties are effectively copy-pastes, so it does not
suffer from this issue).
This patch:
1. Defers computation of registstered custom properties using font-relative
units
2. Keeps track of custom properties utilizing font-relative units
3. Keeps track of non-custom, font-related properties making variable
references
4. Expands the cycle detection to non-custom properties
Because of 1, this patch causes registered custom property using
font-relative units to resolve as if they're unregistered - this will be
addressed in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D196194
This implements a similar optimization as WebKit's, see the bug comment.
This should be specially useful for sites with lots of custom
properties.
This is a high-confidence win on this speedometer subtest:
* 1.9x faster in style updates.
* 4.2x faster in layout object destruction (we no longer free the huge
custom properties map).
* Also speeds up paint and layout a bit, probably from less memory
churn.
Differential Revision: https://phabricator.services.mozilla.com/D198308
This patch also updates the bug ID for a FIXME leftover from bug 1840478
to bug 1869476, since the same FIXME is added in D190758.
Co-authored-by: Frederic Wang <fred.wang@free.fr>
Depends on D191322
Differential Revision: https://phabricator.services.mozilla.com/D190758
This will make possible to animate custom properties. For now, the
animation code keeps only dealing with PropertyDeclarationId::Longhand,
so behavior is unchanged.
Co-authored-by: Frederic Wang <fred.wang@free.fr>
Depends on D195972
Differential Revision: https://phabricator.services.mozilla.com/D190816
PropertyId predates NonCustomPropertyId. Now that we have it, we can
clean up a bit the code.
The idea is to make PropertyId and AnimatedPropertyId basically the
same, so that conversions can be improved in bug 1846516.
While at it make NonCustomPropertyId a u32.
Differential Revision: https://phabricator.services.mozilla.com/D196415
Since registered custom properties can be specified to not inherit,
DevTools need to retrieve this information in order to display accurate
data in the rules view.
The method signature is changed and now take a Document so we can lookup
the registry.
The existing test is updated with registered and unregistered custom properties.
Next patch in queue handles the impact in DevTools code.
Differential Revision: https://phabricator.services.mozilla.com/D194629
If the initial values of custom property registrations contain viewport
units, changing the viewport will result in recomputing the initial
values.
Differential Revision: https://phabricator.services.mozilla.com/D194668
This is needed to be able to use chrome environment variables in
chrome stylesheets and have them work in non-chrome documents.
This will be used to communicate the right transition duration in
scrollbars.css, but should also be useful to have the right base URI for
<url>-typed custom properties.
Differential Revision: https://phabricator.services.mozilla.com/D193048
This fixes rendering of background-image when CSS zoom is in effect.
Note that we want to scale the resolution by the _inverse_ of the
zoom, since having a higher image resolution means that the CSS
size gets shrunk and viceversa.
Differential Revision: https://phabricator.services.mozilla.com/D192130
When colors are converted to sRGB to render onto the display, make sure
that they are within sRGB gamut limits.
Gamut mapping is implemented according to:
https://drafts.csswg.org/css-color-4/#gamut-mapping
The color-mix-non-srgb-001 test is checking the expected result in
sRGB, which happens to be out of gamut limits, but because the test
is for color-mix and not gamut mapping, I changed the expected
results to the color space of the mix.
The svg reftest now has an increased fuzzy to allow for the final colors
to be gamut mapped. Gamut mapping is dependent of available hardware, so
we can't pin down exact colors for the result.
Differential Revision: https://phabricator.services.mozilla.com/D191083
When colors are converted to sRGB to render onto the display, make sure
that they are within sRGB gamut limits.
Gamut mapping is implemented according to:
https://drafts.csswg.org/css-color-4/#gamut-mapping
The color-mix-non-srgb-001 test is checking the expected result in
sRGB, which happens to be out of gamut limits, but because the test
is for color-mix and not gamut mapping, I changed the expected
results to the color space of the mix.
The svg reftest now has an increased fuzzy to allow for the final colors
to be gamut mapped. Gamut mapping is dependent of available hardware, so
we can't pin down exact colors for the result.
Differential Revision: https://phabricator.services.mozilla.com/D191083
Add a simple getter for the color interpolation method with is stored on
each of the structs in the union. This just makes it easier to get.
Differential Revision: https://phabricator.services.mozilla.com/D192105
There are cases where we can run a selector match to realize that some DOM mutations
will not make a difference in the relative selector match state, which avoids
O(n^2) behaviour under some circumstances.
Differential Revision: https://phabricator.services.mozilla.com/D191307
The stylist is kept in order to avoid needing to unwrap it each time a
stylist is used.
Because a computed context is always required to make a custom
properties builder, cascade_custom_properties_with_context is renamed to
cascade_custom_properties (and the previous cascade_custom_properties,
which did not require a computed context, is removed).
Differential Revision: https://phabricator.services.mozilla.com/D191613
We have ArcSelectorList for selector-lists that are cheap to copy.
For bug 1859915 and related, what we're going to end up doing is probably
expanding into the SelectorList of the parent rule unconditionally, at least
for the "single bare &" case.
It'd be nice to unify SelectorList implementations as preparation for that, and
make them cheaper to clone in general.
My proposal is making SelectorList a tagged pointer to either a single
selector, or to a ThinArc, effectively preserving the SmallVec<> optimization
we have now. This patch implements that proposal.
Depends on D191361
Differential Revision: https://phabricator.services.mozilla.com/D191362
When colors are converted to sRGB to render onto the display, make sure
that they are within sRGB gamut limits.
Gamut mapping is implemented according to:
https://drafts.csswg.org/css-color-4/#gamut-mapping
The color-mix-non-srgb-001 test is checking the expected result in
sRGB, which happens to be out of gamut limits, but because the test
is for color-mix and not gamut mapping, I changed the expected
results to the color space of the mix.
Differential Revision: https://phabricator.services.mozilla.com/D191083
Currently Firefox properly performs validation of an @property rule, as
defined in [1]. However when such a rule is invalid, it only does not
register the custom property instead of dropping the whole rule. Other
implementations also follow that aproach and existing web platform tests
disagree with the specification [2].
This patch aligns Firefox's behavior with the specification, by moving
@property validation during parsing and dropping invalid rules. Tests
are updated as follows:
1. /css/css-properties-values-api/at-property-cssom.html
Existing tests that don't have the three descriptors (syntax,
inherit, initial-value) are invalid and now the test verifies
no corresponding rules are exposed via CSSOM. `--no-initial-value`
is renamed `--no-initial-color-value` and its legacy tests are
kept for a new @property `--no-initial-universal-value` which uses
the universal syntax (so initial value is optional). Some dummy
descriptors are added for --tab\ttab so that it remains valid.
Similarly, we ensure --valid-whitespace's syntax (space-separated)
and initial-value (comma-separated) agree.
2. /css/css-properties-values-api/at-property.html
Existing `test_descriptor()` tests are trying an @property with
a single specified descriptor and so are always invalid. To work
around that, we tweak `test_descriptor()` so that it can build a
valid descriptor instead. The `syntax` and `inherits` fallback
to universal and true respectively while the `initial-value`
descriptor is built from the `syntax`. An extra parameters is
introduced in case the caller wants to provide these values
directly. Finally, when the expected value is null the function
instead verifies that the rule is really dropped.
2.1. Some existing syntax tests are registering rules with unquoted
syntax value 'red', 'rgb(255, 0, 0)', 'color', 'foo | bar' and
expect to obtain a rule with an empty syntax string, suggesting some
kind of invalidity handling (cf similar tests). We interpret the
first two as "specifying a color value", quotes are added and the
first one actually becomes a valid custom-ident. The last two already
have a similar quoted version, so we just interpret them as
"missing quotes".
2.2. Given the previous 'red' custom-ident, we add tests for invalid
custom-ident as defined in [3].
2.3. Some existing `syntax` tests are checking that we must have
"pipe between components" and no "leading bar" and are again expecting
a rule with an empty syntax string. We fix the apparent mistake of
missing quotes and provide initial values that could potentially be
interpreted as correct by implementations accepting these invalid
syntaxes.
2.4. One `initial-value` test is checking "var(--x)" but that is
not computationally independent so tweak the test to check that
makes the @property rule invalid. Also add a similar '3em' test
mentioned in the spec.
2.5. Some `inherits` tests verify that invalid rules are interpreted
as false. It seems they should instead be treated as if it does not
exist and so should make the @property rule invalid.
[1] https://drafts.css-houdini.org/css-properties-values-api-1/#at-property-rule
[2] https://github.com/w3c/css-houdini-drafts/issues/1098
[3] https://drafts.csswg.org/css-values-4/#custom-idents
Differential Revision: https://phabricator.services.mozilla.com/D190444
After bug 1840478, non-inherited custom properties using their initial
values are represented as absent from `ComputedCustomProperties` in
order to save memory. Wherever the values of such properties are
requested, it is necessary to fallback to any registered initial value.
However, this makes difficult to properly enumerate custom properties
for exposure via the `CSSStyleDeclaration.item()` API and indeed our
current implementation only exposes the properties actually present in
`ComputedCustomProperties`.
Additionally, such a representation conflicts with pre-existent
representation of guaranteed-invalid values as absent values, causing
some issues e.g. bad handling of invalid at computed-value time [1] [2].
This patch changes `ComputedCustomProperties` so that registered initial
values are always stored in the `non_inherited` map, immediately fixing
the issue with `CSSStyleDeclaration.item()` and preparing follow-up
work on guaranteed-invalid values.
To avoid excessive increase of memory usage, the `non_inherited` map
becomes ref-counted. The associated Stylist contains an up-to-date
ComputedCustomProperties with registered custom properties that have
initial values, and the `non_inherited` map can generally just be
shallow-cloned from it.
A new test `get-computed-style-enumeration.html` is added to make sure
custom properties are correctly exposed when enumerating
`CSSStyleDeclaration` as a list. A similar but more restricted version
already exists: `cssstyledeclaration-registered-custom-properties.html`.
Two test cases are also added to `determine-registration.html` in order
to cover some issue previously detected during the review of
`get_custom_property_initial_values`.
[1] https://drafts.csswg.org/css-variables-2/#invalid-at-computed-value-time
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1855946
Differential Revision: https://phabricator.services.mozilla.com/D189999
