We null-initialize all of the other pointer members in NewPerSpanData; we
should do the same for these ones, for consistency & robustness.
(In practice, the callers end up initializing these members before reading them
anyway, so it's been benign that we weren't initializing them. But better
for safety & futureproofing to have them reliably initialized.)
Differential Revision: https://phabricator.services.mozilla.com/D210106
Values were static_casted where required. Some functions in WritingModes.h were
rewritten such that bitwise operations aren't being used. Added static_casts to
avoid (debug) build errors from debugging printfs in layout/tables/nsCellMap.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D205510
This was just a silly trivial error in the original implementation. We shouldn't apply
the inset value to nested spans within the line, only to the root span.
Differential Revision: https://phabricator.services.mozilla.com/D203786
This simplifies our combobox code a bit more:
* Reflow() is only needed to compute the label isize.
* Frame construction uses a setup more similar to <input type=file> to
get the right frame tree, removing a bunch of special code.
* Lots of special code removed all over the place.
Differential Revision: https://phabricator.services.mozilla.com/D203010
Extend the per-frame-class bit we have to devirtualize IsLeaf to also
devirtualize IsFrameOfType. That is, move this data to FrameClasses.py.
This was done by going through all the frame classes, trying to preserve
behavior.
The only quirky thing is that I had to add two more trivial frame
classes, `nsAudioFrame` for audio elements, and
`nsFloatingFirstLetterFrame`. That's because these frame classes were
returning different answers at runtime, but they do this only on
conditions that trigger frame reconstruction (floating, and being an
audio element, respectively).
Differential Revision: https://phabricator.services.mozilla.com/D194703
A simple form of balance for short blocks, implemented by incrementally reducing
the effective inline-size used during line-breaking, up to the point where an
extra line would be created.
This fails the test text-wrap-balance-line-clamp-001.html, but it's unclear to me
if that test is correct (see https://github.com/w3c/csswg-drafts/issues/9310).
If we do want the behavior expected by that test, an additional patch to handle
the interaction with line-clamp will be required.
Depends on D187543
Differential Revision: https://phabricator.services.mozilla.com/D187544
A simple form of balance for short blocks, implemented by incrementally reducing
the effective inline-size used during line-breaking, up to the point where an
extra line would be created.
This fails the test text-wrap-balance-line-clamp-001.html, but it's unclear to me
if that test is correct (see https://github.com/w3c/csswg-drafts/issues/9310).
If we do want the behavior expected by that test, an additional patch to handle
the interaction with line-clamp will be required.
Depends on D187543
Differential Revision: https://phabricator.services.mozilla.com/D187544
A simple form of balance for short blocks, implemented by incrementally reducing
the effective inline-size used during line-breaking, up to the point where an
extra line would be created.
This fails the test text-wrap-balance-line-clamp-001.html, but it's unclear to me
if that test is correct (see https://github.com/w3c/csswg-drafts/issues/9310).
If we do want the behavior expected by that test, an additional patch to handle
the interaction with line-clamp will be required.
Depends on D187543
Differential Revision: https://phabricator.services.mozilla.com/D187544
Existing failures:
* `-webkit-line-clamp` with `baseline-source: last`: Clamped lines are still
considered for baseline contribution. (e.g. if there are 4 lines with
`-webkit-line-clamp: 3`, we should pick the third line, but we pick the 4th.
* `table` with 2 captions, one above and another below the table: We seem to
not draw the latter caption.
* `inline-flex` with `flex-direction: column` and `baseline-source: last`:
Calculated baseline is the first baseline.
Differential Revision: https://phabricator.services.mozilla.com/D173887
Existing failures:
* `-webkit-line-clamp` with `baseline-source: last`: Clamped lines are still
considered for baseline contribution. (e.g. if there are 4 lines with
`-webkit-line-clamp: 3`, we should pick the third line, but we pick the 4th.
* `table` with 2 captions, one above and another below the table: We seem to
not draw the latter caption.
* `inline-flex` with `flex-direction: column` and `baseline-source: last`:
Calculated baseline is the first baseline.
Differential Revision: https://phabricator.services.mozilla.com/D173887
Existing failures:
* `-webkit-line-clamp` with `baseline-source: last`: Clamped lines are still
considered for baseline contribution. (e.g. if there are 4 lines with
`-webkit-line-clamp: 3`, we should pick the third line, but we pick the 4th.
* `table` with 2 captions, one above and another below the table: We seem to
not draw the latter caption.
* `inline-flex` with `flex-direction: column` and `baseline-source: last`:
Calculated baseline is the first baseline.
Differential Revision: https://phabricator.services.mozilla.com/D173887
Existing failures:
* `-webkit-line-clamp` with `baseline-source: last`: Clamped lines are still
considered for baseline contribution. (e.g. if there are 4 lines with
`-webkit-line-clamp: 3`, we should pick the third line, but we pick the 4th.
* `table` with 2 captions, one above and another below the table: We seem to
not draw the latter caption.
* `inline-flex` with `flex-direction: column` and `baseline-source: last`:
Calculated baseline is the first baseline.
Differential Revision: https://phabricator.services.mozilla.com/D173887
Existing failures:
* `-webkit-line-clamp` with `baseline-source: last`: Clamped lines are still
considered for baseline contribution. (e.g. if there are 4 lines with
`-webkit-line-clamp: 3`, we should pick the third line, but we pick the 4th.
* `table` with 2 captions, one above and another below the table: We seem to
not draw the latter caption.
* `inline-flex` with `flex-direction: column` and `baseline-source: last`:
Calculated baseline is the first baseline.
Differential Revision: https://phabricator.services.mozilla.com/D173887
Existing failures:
* `-webkit-line-clamp` with `baseline-source: last`: Clamped lines are still
considered for baseline contribution. (e.g. if there are 4 lines with
`-webkit-line-clamp: 3`, we should pick the third line, but we pick the 4th.
* `table` with 2 captions, one above and another below the table: We seem to
not draw the latter caption.
* `inline-flex` with `flex-direction: column` and `baseline-source: last`:
Calculated baseline is the first baseline.
Differential Revision: https://phabricator.services.mozilla.com/D173887
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
For ToResolvedValue implementation purposes we wouldn't need to split
out the vertical / font / line-height arguments and we could just pass
around the ComputedStyle, but the lh unit would need that distinction,
(because computing lh on font properties should use the parent style).
Differential Revision: https://phabricator.services.mozilla.com/D168705
