With this patch, all the WPTs for initial value validation pass, except
for one whose syntax fails to parse (see bug 1843988).
Depends on D183806
Differential Revision: https://phabricator.services.mozilla.com/D183807
If we unconditionally return `Err(())`, the entire composition fails and
we use the keyframe values always.
Basically, we should just use the effect value "per item" when it falls back to
discrete (i.e. non-additive), for composition. So we have to implement
Procedure::Add and Procedure::Accumulate to avoid rejecting everything in
GridTemplateComponent.
Differential Revision: https://phabricator.services.mozilla.com/D183623
Font-relative units are not computationally independent, so they cannot
be in the initial value.
Drive-by, but this patch also switches to defining the fields of
ParsingMode using bit shifting to match Gecko's ParsingMode declaration.
Differential Revision: https://phabricator.services.mozilla.com/D183806
Introduce the concept of "header bar" colors, and use them when we don't draw
to the titlebar directly (in which case we use the titlebar / caption colors).
This maps to the KDE "header" colors, and allows us to:
* Fix this bug, by not blindly using titlebar colors. This restores
previous behavior for most themes, which used to use the menubar
colors, and actually enhances it by allowing them to react to
window-inactive states.
* Preserve the nice behavior on places we know it's good (that is, keep
bug 1704086 fixed, for example). This is done by special-casing
Adwaita/Breeze/Yaru, which is kinda lame, but it doesn't seem too
terrible.
* More thoroughly respect KDE system settings.
Differential Revision: https://phabricator.services.mozilla.com/D182888
The merge logic in try_product_in_place could not be used because it
expected the rhs node to be a leaf already. Now it tries to resolve the
rhs to a number before checking validity. This allows the use of the
logic during parsing as well. When simplifying the rhs is already a
node as it used to be, so the resolve should hit the Leaf case anyway
and return early, so the overhead is negligible.
Differential Revision: https://phabricator.services.mozilla.com/D183573
Some basic clean-up. I want to do this before doing bigger changes in
bug 1843044.
There's tons more code that can get cleaned-up on the widget side, but
let's start with this.
Differential Revision: https://phabricator.services.mozilla.com/D183622
The merge logic in try_product_in_place could not be used because it
expected the rhs node to be a leaf already. Now it tries to resolve the
rhs to a number before checking validity. This allows the use of the
logic during parsing as well. When simplifying the rhs is already a
node as it used to be, so the resolve should hit the Leaf case anyway
and return early, so the overhead is negligible.
Differential Revision: https://phabricator.services.mozilla.com/D183573
In MathML Core, the recommendation is to directly use the proper
character from the Mathematical Alphanumeric Symbols instead of the
mathvariant attribute. The exception is for automatic italicization on
single-char `<mi>` element. This is implemented via a new text-transform
value "math-auto" [1] which is the default on the `<mi>` element. The
mathvariant attribute is now restricted to that element and to value
"normal" in order to force upright text instead [2]. This CL implements
this restriction together with that new text-transform value under the
mathml.legacy_mathvariant_attribute.disabled flag.
Some legacy MathML cases where math-auto alone does not work are
still handled via MathMLTextRunFactory.
[1] https://w3c.github.io/mathml-core/#new-text-transform-values
[2] https://w3c.github.io/mathml-core/#the-mathvariant-attribute
Differential Revision: https://phabricator.services.mozilla.com/D172395
In MathML Core, the recommendation is to directly use the proper
character from the Mathematical Alphanumeric Symbols instead of the
mathvariant attribute. The exception is for automatic italicization on
single-char `<mi>` element. This is implemented via a new text-transform
value "math-auto" [1] which is the default on the `<mi>` element. The
mathvariant attribute is now restricted to that element and to value
"normal" in order to force upright text instead [2]. This CL implements
this restriction together with that new text-transform value under the
mathml.legacy_mathvariant_attribute.disabled flag.
Some legacy MathML cases where math-auto alone does not work are
still handled via MathMLTextRunFactory.
[1] https://w3c.github.io/mathml-core/#new-text-transform-values
[2] https://w3c.github.io/mathml-core/#the-mathvariant-attribute
Differential Revision: https://phabricator.services.mozilla.com/D172395
In MathML Core, the recommendation is to directly use the proper
character from the Mathematical Alphanumeric Symbols instead of the
mathvariant attribute. The exception is for automatic italicization on
single-char `<mi>` element. This is implemented via a new text-transform
value "math-auto" [1] which is the default on the `<mi>` element. The
mathvariant attribute is now restricted to that element and to value
"normal" in order to force upright text instead [2]. This CL implements
this restriction together with that new text-transform value under the
mathml.legacy_mathvariant_attribute.disabled flag.
Some legacy MathML cases where math-auto alone does not work are
still handled via MathMLTextRunFactory.
[1] https://w3c.github.io/mathml-core/#new-text-transform-values
[2] https://w3c.github.io/mathml-core/#the-mathvariant-attribute
Differential Revision: https://phabricator.services.mozilla.com/D172395
Introduce a product and invert node so that calculations can be done
after parsing, mostly because we will introduce the sign() node which is
not distributive.
Differential Revision: https://phabricator.services.mozilla.com/D180681
Per spec
https://drafts.csswg.org/css-shapes-1/#basic-shape-computed-values, and
the spec issue, https://github.com/w3c/csswg-drafts/issues/9053,
all <basic-shape-rect> functions compute to the equivalent inset() function.
i.e.
`xywh(x y w h)` computes to
`inset(y calc(100% - x - w) calc(100% - y - h) x)`
The basic concept is to use `BasicShapeRect` as the specified value of
`<basic-shape-rect>`, i.e. inset()/xywh()/rect(), and its computed value is
the equivalent `InsetRect`, and so it becomes possible to interpolate among
these three functions.
Also, we can drop BuildXywhPath() and ComputeRect() because now there is
only inset() function when building gfx::Path.
Besides, tweak the test, offset-path-shape-xywh-003.html, because the original
test, `xywh(10% 10% 80% 80%)`, has to calculate `calc(100% - 10% - 80%)`.
Its result is `Percentage(0.099999964)` in Rust code, and then it makes us
compute an imprecision inset rect when building the gfx::path, which results in
a transform with the sub-pixel translation. So change it to
`xywh(10% 10% 90% 90%)` to avoid adding fuzzy tolerance.
Differential Revision: https://phabricator.services.mozilla.com/D183221
ThinArc is way more complex than it needs to be, and miri complains
about various things when using the selectors crate with it.
This doesn't fully fix miri, but it gets much closer. ThinArc becomes
just an alias for Arc<HeaderSlice<>>. This allows to simplify the
bindings to ArcSlice too, since now the existing Arc<> code can just be
used.
Differential Revision: https://phabricator.services.mozilla.com/D183011
Now that we don't need the nscoord-resolving thing, we can actually just
call into rust to do this, and avoid the code duplication.
Differential Revision: https://phabricator.services.mozilla.com/D183078
This improves the testcase in bug 1837673, because it means that we only
check attributes once. Before this patch, we would check them twice: First,
the SimpleFilter path would check for the presence of the attribute, and then
later we would enumerate attributes again to check the attribute value.
Now we don't use the SimpleFilter path anymore and go straight to attribute
enumeration.
Differential Revision: https://phabricator.services.mozilla.com/D181349
The goal here is to inline the loop and attribute name check into the caller.
Once an attribute with a matching name is found, we do the remainder of the
checks (namespace, attribute value) with a function call.
The `#[inline(always)]` annotation was needed in a local non-PGO --enable-release build.
Without #[inline(always)]: https://share.firefox.dev/46SQUMn
With #[inline(always)] (18% faster): https://share.firefox.dev/44CvC3g
Differential Revision: https://phabricator.services.mozilla.com/D181348
The TLDR is that our first-line implementation is complete madness, but
I'm not fixing bug 1465474 yet.
The guarantee that first-line style reparenting relies on is that
reparenting shouldn't change reset properties (that's why we had all
this "style to inherit ignoring first-line" to inherit reset
properties). Bug 1839223 broke this guarantee in the case the mapped
attribute declarations are reused / mutated (which is something we want
to do for performance).
What's going on in the test-case is that the old style's rule-node
declarations are mutated by the mapped attributes code. Re-cascading the
old styles yields a different `float` property value.
When a style change that causes a reframe like this one happens, we
don't update the frame tree styles with the new styles: it'd be wrong
and also useless work.
First-line reparenting happens after we've recomputed the styles, but
before we've reframed as needed. In this intermediate state, the frame
remains with the old (floated) style, but the ::first-line reparenting
code isn't aware that this frame is going away, so it happily
re-cascades and updates the style anyways, creating a floated
frame that has float: none in its computed style information.
This causes the frame destruction code to crash.
This patch restores that guarantee that ::first-line doesn't change
reset properties by re-using the "reset properties cache" code-path.
This is also simpler since it avoids us having to compute the "parent
ignoring ::first-line" style.
The code is also more explicit with the new enum rather than just an
Option.
Differential Revision: https://phabricator.services.mozilla.com/D182769
-moz-menubarhovertext has one usage that can go away once we remove
windows 7 / 8 so not touching that yet.
Depends on D182896
Differential Revision: https://phabricator.services.mozilla.com/D182897
The TLDR is that our first-line implementation is complete madness, but
I'm not fixing bug 1465474 yet.
The guarantee that first-line style reparenting relies on is that
reparenting shouldn't change reset properties (that's why we had all
this "style to inherit ignoring first-line" to inherit reset
properties). Bug 1839223 broke this guarantee in the case the mapped
attribute declarations are reused / mutated (which is something we want
to do for performance).
What's going on in the test-case is that the old style's rule-node
declarations are mutated by the mapped attributes code. Re-cascading the
old styles yields a different `float` property value.
When a style change that causes a reframe like this one happens, we
don't update the frame tree styles with the new styles: it'd be wrong
and also useless work.
First-line reparenting happens after we've recomputed the styles, but
before we've reframed as needed. In this intermediate state, the frame
remains with the old (floated) style, but the ::first-line reparenting
code isn't aware that this frame is going away, so it happily
re-cascades and updates the style anyways, creating a floated
frame that has float: none in its computed style information.
This causes the frame destruction code to crash.
This patch restores that guarantee that ::first-line doesn't change
reset properties by re-using the "reset properties cache" code-path.
This is also simpler since it avoids us having to compute the "parent
ignoring ::first-line" style.
The code is also more explicit with the new enum rather than just an
Option.
Depends on D182768
Differential Revision: https://phabricator.services.mozilla.com/D182769
Bug 1837700 comment 14 is right. I can reproduce it by toggling off
scroll-anchoring by pref, and accessing:
data:text/html,<div contenteditable>
So that we load contenteditable.css which hits the issue.
Differential Revision: https://phabricator.services.mozilla.com/D182666
This effectively undoes bug 1506760, preventing the reallocation of the
reference set.
This was done for UA sheet sharing (bug 1474793), but we can handle this
fine now (UA sheets don't have variable references anyways).
Depends on D182170
Differential Revision: https://phabricator.services.mozilla.com/D182171
This is not the whole validation that needs to happen, but we need to do
this anyways for the universal-syntax.
Rename validate_syntax to validate_initial_value since that's what it
does.
Differential Revision: https://phabricator.services.mozilla.com/D182169
This implements script registration and some basic validity checks so
that we start keeping track of custom properties in the CascadeData and
in script.
Differential Revision: https://phabricator.services.mozilla.com/D182110
Now that we just use a single mutable context we can simplify this by
using the same representation. The different type is still useful
because once we enter on a nested context there's some checks we can
omit.
This should make parsing slightly faster.
Differential Revision: https://phabricator.services.mozilla.com/D181802
Allow the following syntax for gradients:
`linear-gradient(in lab to right, red, blue)`
The patch will parse and make available the interpolation method, but no
rendering changes are made, so all gradients will still render in srgb.
Differential Revision: https://phabricator.services.mozilla.com/D181162
Due to the prioritization rules for custom highlights, it is not feasible to rely on cascading.
Instead, highlights need to be stacked by their priority (and order of insertion).
Text and background color of the highest-prioritized highlight which defines that property should be used.
Since highlights are implemented as special `Selection`s, the algorithm that determines the prevailing selection for a text frame needed to be adapted to instead return a list of selections.
Differential Revision: https://phabricator.services.mozilla.com/D181143
Allow the following syntax for gradients:
`linear-gradient(in lab to right, red, blue)`
The patch will parse and make available the interpolation method, but no
rendering changes are made, so all gradients will still render in srgb.
Differential Revision: https://phabricator.services.mozilla.com/D181162
Allow the following syntax for gradients:
`linear-gradient(in lab to right, red, blue)`
The patch will parse and make available the interpolation method, but no
rendering changes are made, so all gradients will still render in srgb.
Differential Revision: https://phabricator.services.mozilla.com/D181162
Instead, lazily schedule evaluation of them before styling, much like we
were doing for SVG.
A subtle tweak is that we only remain scheduled while in the document.
This allows us to use the "in document" bit plus the "mapped attributes
dirty" bit to know our scheduled status. It also prevents doing silly
work for disconnected elements, and having to do hashmap lookups on
adoption and node destruction.
Differential Revision: https://phabricator.services.mozilla.com/D181549
Instead, lazily schedule evaluation of them before styling, much like we
were doing for SVG.
A subtle tweak is that we only remain scheduled while in the document.
This allows us to use the "in document" bit plus the "mapped attributes
dirty" bit to know our scheduled status. It also prevents doing silly
work for disconnected elements, and having to do hashmap lookups on
adoption and node destruction.
Differential Revision: https://phabricator.services.mozilla.com/D181549
While we're at it:
* Hide :-moz-is-html from content. This is barely documented (a google
search for that yields two pages mostly of our UA sheet) and unlikely
to cause any compat impact (plus it's a one-liner to expose it if we
needed to).
* Make that only depend on the document state. It doesn't have any
practical implications since we only use it on html.css which already
has a default namespace.
* Add some documentation on why are these pseudo-classes (rather than
e.g., media queries).
Differential Revision: https://phabricator.services.mozilla.com/D181406
The idea is to make the function small enough that it's fast to inline and
optimize by the compiler. For that:
* Move some complex bits of matches_simple_selector into functions so
that the compiler can put them out of line if it wants.
* Rename a function to be more descriptive and not force it to be
inline (that wasn't measured afaict, comes from the :nth-child(of)
implementation).
Depends on D180591
Differential Revision: https://phabricator.services.mozilla.com/D180592
We are using NonNegative now for offset-path, so just like clip-path, we
have to make sure we don't get the negative radius for circle and ellipse,
and don't get the negative border-radius for inset. Therefore, we have to
convert the computed value into animated value when doing interpolation,
and then clamp the value to make sure it is always >= 0 when converting
it back to computed value, just like what we do for clip-path in Bug 1512883.
Also drop the normalization of SVGPathData in AnimationInfo when
preparing offset-path for compositor animations. It's useless because we
"always" do normalization in SVGPathData::animate().
Differential Revision: https://phabricator.services.mozilla.com/D180284
We rewrite the data structure of OffsetPath to support all basic shapes.
However, We don't build the gfx::Path for basic shapes other than path()
for now because the current caching mechanism (on the main thread) doesn't
work for basic shapes. It's layout dependent.
Note:
1. Update offset-path-interpolation-006.html to make sure the start value
and the end value have `at <position>`. `offset-path` doesn't set center
as default for `at <position>`, so if any of the values omits the
`at <position>`, we expect they are not interpolated in Gecko.
This is different from Blink, they still use center as the default value
for interpolation.
2. We still have some failures in offset-path-interpolation-006.html
beacuse we don't clamp the negative radius/radii and the negative
border-radius. We will handle it in the following patches.
3. We will add `<coord-box>` in the later patch.
4. Adding Deserialize and Serialize is necessary for compositor
animations.
Differential Revision: https://phabricator.services.mozilla.com/D179627
The omitted postion has special meaning for offset-path. It defaults to using
offset-position as the circle/ellipse center if the explicit center is
not given. Just like what we do for ray(), here we also use
PositionOrAuto for it.
We omit this component if it is not given when serializing offet-path,
and preserve the value even if it specifies the default value, for the
same reason.
For shape-outside and clip-path, we don't change their behaviors for now.
This bug is for offset-path and we will use it in the following patches.
We should fix them in Bug 1837340.
Differential Revision: https://phabricator.services.mozilla.com/D179626
For outline shapes, fill-rule should be ignored. We add the flag in
the parser of BasicShape, so offset-path can use this flag to ignore
fill-rule.
Note: "ShapeType" means this property uses filled shapes or outline
shapes. For outline shapes, we ignore fill-rule. This is from the
concept of `<outline-shape>` and `<filled-shape>` in
https://github.com/w3c/csswg-drafts/issues/3468#issue-393916361
No behavir change in this patch, just add the ability for offset-path to
ignore `<fill-rule>` when combining all basic shapes into offset-path.
Differential Revision: https://phabricator.services.mozilla.com/D179625
The definition of `<basic-shape>` includes other types of basic shapes,
e.g. path(), xywh(), rect(). So we put them together to match the spec.
However, some properties only use the subset of basic shapes, so we use
the bitflags to choose the supported basic shape at the parse time.
Also, remove StyleBasicShapeType because no one uses it.
Only refactoring in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D179624
Layer insertion may change the order of styles, so we may need to fully
invalidate.
Without this change, bug 1838045 makes
layer-statement-before-import.html fail.
Differential Revision: https://phabricator.services.mozilla.com/D180929
At least when the containers are different.
For now check that by doing a somewhat simplified test (checking
sibling-ness).
The new flag can be useful to optimize container query restyles on
resizes too, in the future.
Differential Revision: https://phabricator.services.mozilla.com/D179268
The CSS properties in the list are all shipped. Since we still don't support use
counter for developing CSS properties since this bug opens, I assume this
feature is not critical. Hence the removal of the comment.
Differential Revision: https://phabricator.services.mozilla.com/D180771
Zach Hoffman
Mike Hommey
Boris Chiou
Natalia Csoregi
Gregory Pappas
Emilio Cobos Álvarez
Tiaan Louw
Frederic Wang
Cristian Tuns
Iulian Moraru
Rob Buis
Markus Stange
Noemi Erli
CanadaHonk
Cosmin Sabou
Jan-Niklas Jaeschke
Sandor Molnar
Emily McDonough
Norisz Fay
Narcis Beleuzu
Ting-Yu Lin
David Shin