This patch introduces functional pseudo parameters, i.e. `::highlight(foo)`,
for `getComputedStyle()`. This required adapting the parse algorithm (`nsCSSPseudoElements::ParsePseudoElement()`) and forwarding the functional pseudo parameter into the style engine.
Differential Revision: https://phabricator.services.mozilla.com/D183773
When iterating flex line and flex item in ReflowChildren(), start from the
startmost line and startmost item with respect to the flex container's
writing-mode. This is equivalent to iterate the items in visual order, which is
necessary to compute the item's position correctly, because any shift to the
startmost line or startmost item can affect later ones.
Also, change a condition in `Reflow()` to `aReflowInput.IsInFragmentedContext()`
so that the necessary data can be updated when the flex container fragment is
reflowed in the last column. Otherwise, there will be "unexpected max block
size" assertions [1] while running `layout/generic/crashtests/1666592.html`.
[1] https://searchfox.org/mozilla-central/rev/e9b8c73771d0038214c69f17c5934ba8ae049799/layout/generic/nsFloatManager.cpp#111
Differential Revision: https://phabricator.services.mozilla.com/D183193
In bug 1844755, a bunch of the time is spent allocating initial values.
There used to be more document-dependent initial values before
bug 1834487, but now that's only about default-font and direction.
This improves the situation by sharing initial structs that don't depend
on the document.
Differential Revision: https://phabricator.services.mozilla.com/D184256
We need to inline Self::new() so cbindgen generates the constants, which
is kinda lame, but seems better than duplicating the values and type
definitions.
Differential Revision: https://phabricator.services.mozilla.com/D183921
We need to inline Self::new() so cbindgen generates the constants, which
is kinda lame, but seems better than duplicating the values and type
definitions.
Differential Revision: https://phabricator.services.mozilla.com/D183921
We need to inline Self::new() so cbindgen generates the constants, which
is kinda lame, but seems better than duplicating the values and type
definitions.
Differential Revision: https://phabricator.services.mozilla.com/D183921
This commit removes the runtime flags and related code for the
scriptminsize and scriptsizemultiplier, which have been disabled by
default for a while. The hardcoded default values
kMathMLDefaultScriptSizeMultiplier and kMathMLDefaultScriptMinSizePt
are still used in some places and are preserved for now.
Differential Revision: https://phabricator.services.mozilla.com/D157426
When we recreate the display list, e.g. after tabbing away, we need to
ensure we flush the OffscreenCanvas because our resource handles will be
invalidated. This requires the OffscreenCanvasDisplayHelper to know
which OffscreenCanvas it belongs to, and a worker reference if necessary
to do the dispatching for the flush. Otherwise we would require the
canvas to be updated manually by the web application to repaint.
Differential Revision: https://phabricator.services.mozilla.com/D184324
When fission is enabled we activate all scroll frames that can be activated, so it should not be possible to hit this code. Record this to validate that it is indeed not possible for this to happen.
Differential Revision: https://phabricator.services.mozilla.com/D183742
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
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
OS print drivers/devices know nothing about page dimensions unless we tell
them. Previously, the physical page dimensions (including orientation) have
always been the same, so communicating their dimensions once at the start of
a print has been enough. In preparation for supporting different "physical"
page dimensions (in the immediate future only different page orientations) when
we save to PDF, we need to have the infrastructure to pass dimensions through
on a page-by-page basis. This patch adds that.
None of the PrintTarget subclasses do anything with this extra information yet,
but in a follow-up patch PrintTargetPDF will use this information to create
PDFs with mixed page orientations.
Differential Revision: https://phabricator.services.mozilla.com/D179423
Subtle things:
* We now have shadow trees in NAC, inception! Only a couple lines of
code in the style system had to be changed to match :host rules and
so properly.
* Had to make highlighters.css contentaccessible, because otherwise we
can't load it from the shadow tree. I don't think it's a big deal.
* I removed some of the code from highlighters.css that claimed that
stuff inherited from the html element. That's just no longer true.
* Had to switch from `setAttribute("style", ...)` to `.style = ...;`.
This is needed because CSSOM from chrome code bypasses CSP (as
AnonymousContent did), but setAttribute() doesn't, see bug 1424474.
Differential Revision: https://phabricator.services.mozilla.com/D173998
The fuzzy in the test happens on the round because we use the different way
to draw the round of clip-path (compared to border-radius property) in
the render backend, so there are some tiny differences.
Differential Revision: https://phabricator.services.mozilla.com/D182421
We would like to use these function for all rectangular shape, i.e.
inset()/xywh()/rect(). So rename them to avoid confusion.
No behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D182422
Subtle things:
* We now have shadow trees in NAC, inception! Only a couple lines of
code in the style system had to be changed to match :host rules and
so properly.
* Had to make highlighters.css contentaccessible, because otherwise we
can't load it from the shadow tree. I don't think it's a big deal.
* I removed some of the code from highlighters.css that claimed that
stuff inherited from the html element. That's just no longer true.
* Had to switch from `setAttribute("style", ...)` to `.style = ...;`.
This is needed because CSSOM from chrome code bypasses CSP (as
AnonymousContent did), but setAttribute() doesn't, see bug 1424474.
Differential Revision: https://phabricator.services.mozilla.com/D173998
Subtle things:
* We now have shadow trees in NAC, inception! Only a couple lines of
code in the style system had to be changed to match :host rules and
so properly.
* Had to make highlighters.css contentaccessible, because otherwise we
can't load it from the shadow tree. I don't think it's a big deal.
* I removed some of the code from highlighters.css that claimed that
stuff inherited from the html element. That's just no longer true.
* Had to switch from `setAttribute("style", ...)` to `.style = ...;`.
This is needed because CSSOM from chrome code bypasses CSP (as
AnonymousContent did), but setAttribute() doesn't, see bug 1424474.
Differential Revision: https://phabricator.services.mozilla.com/D173998
