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
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
The CSS Text 3 spec allows this (CSS2 didn't), and other browsers
support it, so for better webcompat/interoperability, we should do the
same. Tests will need updating accordingly.
This first patch enables the property to take effect, but the resulting
layout is not yet correct because the (non-collapsed) whitespace at line
wrap positions needs to be forcibly "hung" into the margin for correct
justification; see following patch.
Differential Revision: https://phabricator.services.mozilla.com/D178210
The CSS Text 3 spec allows this (CSS2 didn't), and other browsers
support it, so for better webcompat/interoperability, we should do the
same. Tests will need updating accordingly.
This first patch enables the property to take effect, but the resulting
layout is not yet correct because the (non-collapsed) whitespace at line
wrap positions needs to be forcibly "hung" into the margin for correct
justification; see following patch.
Differential Revision: https://phabricator.services.mozilla.com/D178210
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
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
This slightly simplifies gfxTextRun::BreakAndMeasureText, and should make it less confusing
to reason about trailing whitespace in nsTextFrame/nsLineLayout.
Differential Revision: https://phabricator.services.mozilla.com/D174377
In my local testing, this seems to be harmless, but we should be alert for reports of any erratic
or poorly-rasterized text that results.
Differential Revision: https://phabricator.services.mozilla.com/D173633
In my local testing, this seems to be harmless, but we should be alert for reports of any erratic
or poorly-rasterized text that results.
Differential Revision: https://phabricator.services.mozilla.com/D173633
Previously, for writing-mode using central baseline alignment (i.e. `vertical-(lr|rl)`,
we simply used the center of content-box in `nsLineLayout::VerticalAlignFrames`.
However, this is incorrect for e.g. a `div` with two lines of text - just like how
its alphabetical baseline is the baseline of the second line of text, the central
baseline should be the centerline of the second line.
Differential Revision: https://phabricator.services.mozilla.com/D172165
Previously, for writing-mode using central baseline alignment (i.e. `vertical-(lr|rl)`,
we simply used the center of content-box in `nsLineLayout::VerticalAlignFrames`.
However, this is incorrect for e.g. a `div` with two lines of text - just like how
its alphabetical baseline is the baseline of the second line of text, the central
baseline should be the centerline of the second line.
Differential Revision: https://phabricator.services.mozilla.com/D172165
Previously, for writing-mode using central baseline alignment (i.e. `vertical-(lr|rl)`,
we simply used the center of content-box in `nsLineLayout::VerticalAlignFrames`.
However, this is incorrect for e.g. a `div` with two lines of text - just like how
its alphabetical baseline is the baseline of the second line of text, the central
baseline should be the centerline of the second line.
Differential Revision: https://phabricator.services.mozilla.com/D172165
Although I haven't been able to reproduce the reporter's OOM crash here, I hope this will avoid
the issue; it certainly improves performance characteristics in my local build.
On the example here, my laptop happily scrolls the text field at 60fps when nothing is selected;
but if the text is selected it can only manage around 40fps, because we lose the clipping
optimization here.
With this change, it maintains 60fps regardless of whether the text is selected (or text-shadow
is present), and memory footprint is substantially reduced.
Differential Revision: https://phabricator.services.mozilla.com/D171318
Before, there existed 3 virtual functions that calculated baselines:
- `GetLogicalBaseline`
- `GetVerticalAlignBaseline`
- `GetNaturalBaselineBOffset`
Each of them had slightly different behaviours:
- `GetLogicalBaseline` would synthesize a baseline if there is no baseline.
Others would simply return `false`.
- `GetNaturalBaselineBOffset` requires the caller to pick which of first/last
baseline to calculate. Others pick on on their own.
- `GetNaturalBaselineBOffset`'s result can be either offset from border box
start/end edge, depending on the caller-supplied baseline. Others always
return offset from border box start edge.
Now:
- `GetNaturalBaselineBOffset` is the sole virtual function.
- `GetLogicalBaseline` exists to support its use, with 2 virtual helper functions:
- `SynthesizeFallbackBaseline` to generate a baseline for elements that
doesn't have one.
- `GetBaselineSharingGroup` to preserve the default baseline picking behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D167990
With this, the old SelectionIterator that expects a per-character array of
SelectionDetails pointers is no longer used anywhere.
Differential Revision: https://phabricator.services.mozilla.com/D170588
This significantly improves performance and reduces memory usage when painting a very long textframe
with some or all of the text selected.
Differential Revision: https://phabricator.services.mozilla.com/D170530
