When tracking tokens, we weren't handling the case of unterminated,
single-char quote.
Test cases are added to cover the fix.
Differential Revision: https://phabricator.services.mozilla.com/D214917
This new InspectorCSSParser makes use of the cssparser crate so DevTools end
up using the same code as the CSS engine.
At the moment, we can't get the token start and end offsets, so we create
a JS wrapper class to compute them in JS. This might be removed if we get
a way to retrieve utf16 position from the cssparser.
The existing lexer xpcshell test is modified so it can run against both js-based
and rust-based lexers.
Differential Revision: https://phabricator.services.mozilla.com/D202909
This wasn't really used anymore.
We are fetching the database from the server runtime in order to support
remote debugging correctly, where frontend CSS may be different from debuggee CSS.
Differential Revision: https://phabricator.services.mozilla.com/D187492
This wasn't really used anymore.
We are fetching the database from the server runtime in order to support
remote debugging correctly, where frontend CSS may be different from debuggee CSS.
Differential Revision: https://phabricator.services.mozilla.com/D187492
Also, add a prefernce for content-box and stroke-box. So we have to
define a new type, TransformBox, and let content-box and stroke-box
behind the preference.
Differential Revision: https://phabricator.services.mozilla.com/D185363
This appears to be unused and only page-actor is reading the list of all pseudo elements
by querying InspectorUtils directly.
Differential Revision: https://phabricator.services.mozilla.com/D185664
In layout, we build a default `path("m 0 0")` for now. We will implement
it later.
Besides, we don't support compositor animations for `url()`, so we don't
have to serialize it for IPC.
Note:
`<url>` includes `url()` and `src()`. For now we only support `url()`.
We should revisit `src()` in Bug 1845390.
Differential Revision: https://phabricator.services.mozilla.com/D184429
I didn't find a single GTK theme that drew something useful for this:
* The container appearance isn't needed. It is a hack needed to get the
right styles for the native checkbox, but that's it, we don't need to
expose it to CSS.
* The label appearance was meant to draw the focus outline but since it
didn't work reliably we've been doing it manually since seven years
ago (see bug 582951 and bug 1312169).
Other platforms also don't use these so this simplifies the code a bit.
Depends on D185279
Differential Revision: https://phabricator.services.mozilla.com/D185286
The font-size math keyword is implemented. It behaves as a font-size: 1em
with the extra fixup due to math-level change (and other legacy MathML
attributes). After that change, the CSS for math-level / font-size: math
is behaving as per the specification, so the math-depth is turned in
nightly.
The adjusting function for font-size: math is modified so that it's
executed only if both font-size: math (otherwise the spec says no scale
should apply) and math-depth (otherwise the scale is 1 and function exists
early anyway) are set on the element.
Differential Revision: https://phabricator.services.mozilla.com/D91744
Note that rect() computes to the equivalent inset() function as well.
i.e. Given `rect(t r b l)`, the equivalent function is
`inset(t calc(100% - r) calc(100% - b) l)`.
The implementation is straightforward, and we don't have to change
anything in cpp because it is always `inset()` when building the gfx::Path.
The tests for clip-path will be added in the following patch.
Differential Revision: https://phabricator.services.mozilla.com/D183528
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
Nicolas Chevobbe