This shouldn't change behavior, but it packs the two arguments to
DestroyFrom into a single thing, and makes nsIFrame::Destroy not so easy
to call without a previous context.
This is a prerequisite to pass aDestroyContext to various things that
right now just mint one, which can cause badness, see bug 1851787 and
related bugs.
It's also a bit nicer to add things there if we need to in the future.
Differential Revision: https://phabricator.services.mozilla.com/D187578
This shouldn't change behavior, but it packs the two arguments to
DestroyFrom into a single thing, and makes nsIFrame::Destroy not so easy
to call without a previous context.
This is a prerequisite to pass aDestroyContext to various things that
right now just mint one, which can cause badness, see bug 1851787 and
related bugs.
It's also a bit nicer to add things there if we need to in the future.
Differential Revision: https://phabricator.services.mozilla.com/D187578
A negative outline-offset value should be clamped per spec as to stop it
from becoming invisible with large negative values.
Spec ref: https://www.w3.org/TR/css-ui-4/#outline-offset
Also added a new WPT reftest for this case as no tests existed prior,
updated related WPT expectations, and updated a few old layout reftests.
Differential Revision: https://phabricator.services.mozilla.com/D185357
A negative outline-offset value should be clamped per spec as to stop it
from becoming invisible with large negative values.
Spec ref: https://www.w3.org/TR/css-ui-4/#outline-offset
Also added a new WPT reftest for this case as no tests existed prior,
updated related WPT expectations, and updated an old layout reftest.
Differential Revision: https://phabricator.services.mozilla.com/D185357
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
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
Basically, the fuzzy happens because the direction angle in circle(),
ellipse(), and inset() can not be equal to the degree perfectly (due to
the arc drawing implementation and the anti-alias around the element),
so we need some tolerance.
And drop offset-path-shape(-ref).html because it has been removed from
the upstream repo.
Differential Revision: https://phabricator.services.mozilla.com/D179630
The data structure of StyleOffsetPath is complicated, so adding some
useful functions to simplify the code.
No behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D181316
We have more readable and faster versions (that just omit the namespace
arg).
Mostly done via sed, with a couple helpers to use the faster lookups
where possible.
Differential Revision: https://phabricator.services.mozilla.com/D181795
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
This was only added for a11y and a11y no longer needs it.
Note that the code in Mac HyperTextAccessibleWrap which used this is no longer used itself and will be removed in bug 1821965.
Differential Revision: https://phabricator.services.mozilla.com/D177745
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
I checked the history, the assert has been commented out since 2000, it was added in 1999. It doesn't seem useful, all the callers basically just get the parent view right before the call.
Differential Revision: https://phabricator.services.mozilla.com/D177862
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
