This patch changes the signature to `GetMinISize()`, `GetPrefISize()`,
`IntrinsicISize` by adding a helper struct as a preparation. Then we can just
add more data such as a percentage basis to the struct without altering the
signature in the future.
When passing `IntrinsicSizeInput` struct down to another helper method, we
generally just pass the original one if the method is computing the intrinsic
size of our own or our anonymous children. If the method is computing our
children's intrinsic contribution, we'll need to create a brand new
`IntrinsicSizeInput` for our children.
Differential Revision: https://phabricator.services.mozilla.com/D219521
This patch changes the signature to `GetMinISize()`, `GetPrefISize()`,
`IntrinsicISize` by adding a helper struct as a preparation. Then we can just
add more data such as a percentage basis to the struct without altering the
signature in the future.
When passing `IntrinsicSizeInput` struct down to another helper method, we
generally just pass the original one if the method is computing the intrinsic
size of our own or our anonymous children. If the method is computing our
children's intrinsic contribution, we'll need to create a brand new
`IntrinsicSizeInput` for our children.
Differential Revision: https://phabricator.services.mozilla.com/D219521
Most frame types have identical or very similar implementation for GetMinISize()
and GetPrefISize(), and many of them already have `IntrinsicISize()` to unify
the implementation. This patch introduces nsIFrame::IntrinsicISize() so that
derived classes only need to override one method.
`nsBlockFrame`, `ColumnSetWrapperFrame`, and `nsColumnSetFrame` are the only
three classes where their `GetMinISize()` and `GetPrefISize()` have significant
differences. Therefore, we rename `GetMinISize()` and `GetPrefISize()` to
`MinISize()` and `PrefISize`, respectively, and use them as helpers to implement
their `IntrinsicISize()`.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D217790
On optimized builds for all desktop platforms, `nsBlockFrame` is 192 bytes, and
`mFloats` is 16 bytes. With this patch, we can reduce the size of `nsBlockFrame`
to 176 bytes, saving 8.33% memory on every `nsBlockFrame` and its derived
subclasses allocated.
On a real webpage like https://en.wikipedia.org/wiki/Firefox, `about:memory`
shows that we allocate 0.36 MB of `nsBlockFrame` consistently. After this patch,
we allocate 0.33 MB, saving approximately 30 KB (0.36 MB * 8.33%) of the memory.
Differential Revision: https://phabricator.services.mozilla.com/D214046
`EnsurePushedFloats()` either returns the existing pushed floats list or creates
a new empty one. Therefore, it can never return nullptr.
Differential Revision: https://phabricator.services.mozilla.com/D214045
On optimized builds for all desktop platforms, `nsBlockFrame` is 192 bytes, and
`mFloats` is 16 bytes. With this patch, we can reduce the size of `nsBlockFrame`
to 176 bytes, saving 8.33% memory on every `nsBlockFrame` and its derived
subclasses allocated.
On a real webpage like https://en.wikipedia.org/wiki/Firefox, `about:memory`
shows that we allocate 0.36 MB of `nsBlockFrame` consistently. After this patch,
we allocate 0.33 MB, saving approximately 30 KB (0.36 MB * 8.33%) of the memory.
Differential Revision: https://phabricator.services.mozilla.com/D214046
`EnsurePushedFloats()` either returns the existing pushed floats list or creates
a new empty one. Therefore, it can never return nullptr.
Differential Revision: https://phabricator.services.mozilla.com/D214045
- Remove "FRAME" for nsBlockFrame state bits for the consistency with other bits.
- Use helpers instead of checking state bits if possible.
- Tweak one line documentation to use C++ comment style.
- Move `GetMarker()` to protected section because it is used only internally.
Differential Revision: https://phabricator.services.mozilla.com/D213698
This is Fantasai's original patch, massively simplified:
* We now can switch whether we're a BFC dynamically (bug 1765615), which
simplifies the patch quite a lot.
* I removed some changes that were specific to pagination but were untested.
I left them as D202814, just in case we need some of those in the future.
All in all this makes the patch much more manageable.
Co-authored-by: Emilio Cobos Álvarez <emilio@crisal.io>
Differential Revision: https://phabricator.services.mozilla.com/D181858
This happens in a similar location to where we find a breakpoint caused by a
change in page name. However, if the breakpoint was caused by something else,
we still need to compute this value so that the next page being constructed
will have the correct page name.
This also "fixes" the WPT /css/printing/page-name-007-print.html, which passed
before this patch just because our previous logic would continue using the last
page value in those cases, which coincidentally matched what was expected.
Part 2 will include a test that specifically detects this discrepency.
Differential Revision: https://phabricator.services.mozilla.com/D196895
This happens in a similar location to where we find a breakpoint caused by a
change in page name. However, if the breakpoint was caused by something else,
we still need to compute this value so that the next page being constructed
will have the correct page name.
This also "fixes" the WPT /css/printing/page-name-007-print.html, which passed
before this patch just because our previous logic would continue using the last
page value in those cases, which coincidentally matched what was expected.
Part 2 will include a test that specifically detects this discrepency.
Differential Revision: https://phabricator.services.mozilla.com/D196895
Right now, we reconstruct frames in response to a change in the CSS
`contain` property or `content-visibility`. This patch tries to optimize
this a bit:
1. Updates involving style containment change continue to force a
reconstruction, due to the need to handle counters/quotes.
2. Updates involving paint/layout containment change only force a
reconstruction if it's needed to handle absolutely/fixed
positioned descendants or floats (for this one, see also bug 1874826).
3. Other containment changes will only force a reflow and repaint.
Per the CSS contain spec, layout, style and paint containments are
enabled for `content-visibility: hidden` and `content-visibility: auto`.
As a consequence, changing `content-visibility` between `hidden` and
`auto` values no longer requires reconstruction. Changing between these
values and `visible` may need a reconstruction although authors may
generally avoid that in practice by forcing `style` containment.
Differential Revision: https://phabricator.services.mozilla.com/D197043
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
The spec explicitly requires that we "must ensure that tab stops continue to line up"
when applying justification to content with preserved white-space that includes tabs.
So when we're computing justification spacing adjustments, we must not apply adjustments
if there is a preserved tab later on the same line; only text after the last tab is to
be justified.
Differential Revision: https://phabricator.services.mozilla.com/D191996
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
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
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
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
Ting-Yu Lin
Butkovits Atila
Jonathan Kew
Emilio Cobos Álvarez
pstanciu
fantasai
Emily McDonough
Stanca Serban
Frédéric Wang
Sandor Molnar
Natalia Csoregi
Narcis Beleuzu
David Shin
Cristian Tuns
Cosmin Sabou
Iulian Moraru
Robert Longson
Noemi Erli