This patch enforces the invariant for `AbsoluteContainingBlock::Reflow()` that
most of the `Reflow()` functions already have.
Differential Revision: https://phabricator.services.mozilla.com/D302429
In order to compute the rect, we need to have all the inline continuations
reflowed and placed. Therefore, this patch introduces a new phase in
`nsBlockFrame::Reflow()` to reflow all the absolute descendants under inline
containing blocks, and adds the absolute descendants' overflow areas into inline
frames and lines' overflow areas.
Differential Revision: https://phabricator.services.mozilla.com/D301184
This is a preparatory refactor for a follow-up commit that introduces a new
flag (for absolutely positioned children). Using a bit-flag enum makes call
sites self-documenting and lets us add more orthogonal options without
expanding the parameter list.
No behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D299915
This also should fix bug 1881942 (placeholder is now scrollable
alongside the textarea).
This makes nsTextControlFrame a subclass of ScrollContainerFrame (with
an inner block), and tweaks layout to match.
It lays out the inner content using block layout and align-content,
rather than bespoke reflow primitives. This makes field-sizing trivial
to implement on top.
This is a bit scary, but simpler in most ways. In particular, it needs
to teach ScrollContainerFrame of the button, because that goes outside
the scrollable area, like scrollbars. That said it needs less
special-cases added than those removed, and it should also be faster
(needs less frames to layout an input with placeholder etc), and match
other browsers better.
The general set-up is:
<text-control-editing-root/>
<placeholder/>
<autofill-preview/>
text-control-editing-root is always inline-block and always displayed
(since it's what grabs the focus / shows the caret). If the
autofill-preview or placeholder are displayed, the editing-root is
zero-width and clipped (note that for placeholder that's guaranteed
because placeholder is only shown with an empty value, but
autofill-preview needs it).
placeholder and autofill-preview are hidden via `display` rather than
visibility. This doesn't make a difference with this patch but it
matters for bug 1977176.
Caret painting needs an extra hop to paint atop the placeholder (no
observable behavior change, but worth calling out).
There is one subtle behavior change, which is that single-line inputs
never report scrollable overflow in the block axis. This matches other
browsers (see the tweak in nsBlockFrame's overflow computation) and is
needed to avoid regressing scrollable-overflow-padding-input.html.
The changes in window_composition_text_querycontent.xhtml are needed
because before this patch, the height of the control editing root was
always the height of the whole textarea. The characters you're composing
might legitimately be taller than the line. Bump the line height so that
that doesn't happen in this test.
Differential Revision: https://phabricator.services.mozilla.com/D293666
This also should fix bug 1881942 (placeholder is now scrollable
alongside the textarea).
This makes nsTextControlFrame a subclass of ScrollContainerFrame (with
an inner block), and tweaks layout to match.
It lays out the inner content using block layout and align-content,
rather than bespoke reflow primitives. This makes field-sizing trivial
to implement on top.
This is a bit scary, but simpler in most ways. In particular, it needs
to teach ScrollContainerFrame of the button, because that goes outside
the scrollable area, like scrollbars. That said it needs less
special-cases added than those removed, and it should also be faster
(needs less frames to layout an input with placeholder etc), and match
other browsers better.
The general set-up is:
<text-control-editing-root/>
<placeholder/>
<autofill-preview/>
text-control-editing-root is always inline-block and always displayed
(since it's what grabs the focus / shows the caret). If the
autofill-preview or placeholder are displayed, the editing-root is
zero-width and clipped (note that for placeholder that's guaranteed
because placeholder is only shown with an empty value, but
autofill-preview needs it).
placeholder and autofill-preview are hidden via `display` rather than
visibility. This doesn't make a difference with this patch but it
matters for bug 1977176.
Caret painting needs an extra hop to paint atop the placeholder (no
observable behavior change, but worth calling out).
There is one subtle behavior change, which is that single-line inputs
never report scrollable overflow in the block axis. This matches other
browsers (see the tweak in nsBlockFrame's overflow computation) and is
needed to avoid regressing scrollable-overflow-padding-input.html.
The changes in window_composition_text_querycontent.xhtml are needed
because before this patch, the height of the control editing root was
always the height of the whole textarea. The characters you're composing
might legitimately be taller than the line. Bump the line height so that
that doesn't happen in this test.
Differential Revision: https://phabricator.services.mozilla.com/D293666
When a transformed absolute containing block fragments across multi-column,
abspos children could paint in the wrong column. This happened because the
abspos display item was built when its placeholder was encountered during
display list traversal, and the placeholder could end up in a different column
than where the abspos should paint.
Extend `DisplayPushedAbsoluteFrames` (now renamed to
`DisplayAbsoluteFramesNotBuiltByPlaceholder`) to also directly build abspos
frames whose placeholder lived in a different continuation subtree. Skip
building those abspos frames when they are later traversed via their
placeholders.
Differential Revision: https://phabricator.services.mozilla.com/D294312
This also should fix bug 1881942 (placeholder is now scrollable
alongside the textarea).
This makes nsTextControlFrame a subclass of ScrollContainerFrame (with
an inner block), and tweaks layout to match.
It lays out the inner content using block layout and align-content,
rather than bespoke reflow primitives. This makes field-sizing trivial
to implement on top.
This is a bit scary, but simpler in most ways. In particular, it needs
to teach ScrollContainerFrame of the button, because that goes outside
the scrollable area, like scrollbars. That said it needs less
special-cases added than those removed, and it should also be faster
(needs less frames to layout an input with placeholder etc), and match
other browsers better.
The general set-up is:
<text-control-editing-root/>
<placeholder/>
<autofill-preview/>
text-control-editing-root is always inline-block and always displayed
(since it's what grabs the focus / shows the caret). If the
autofill-preview or placeholder are displayed, the editing-root is
zero-width and clipped (note that for placeholder that's guaranteed
because placeholder is only shown with an empty value, but
autofill-preview needs it).
placeholder and autofill-preview are hidden via `display` rather than
visibility. This doesn't make a difference with this patch but it
matters for bug 1977176.
Caret painting needs an extra hop to paint atop the placeholder (no
observable behavior change, but worth calling out).
There is one subtle behavior change, which is that single-line inputs
never report scrollable overflow in the block axis. This matches other
browsers (see the tweak in nsBlockFrame's overflow computation) and is
needed to avoid regressing scrollable-overflow-padding-input.html.
The changes in window_composition_text_querycontent.xhtml are needed
because before this patch, the height of the control editing root was
always the height of the whole textarea. The characters you're composing
might legitimately be taller than the line. Bump the line height so that
that doesn't happen in this test.
Differential Revision: https://phabricator.services.mozilla.com/D293666
When a transformed absolute containing block fragments across multi-column,
abspos children could paint in the wrong column. This happened because the
abspos display item was built when its placeholder was encountered during
display list traversal, and the placeholder could end up in a different column
than where the abspos should paint.
Extend `DisplayPushedAbsoluteFrames` (now renamed to
`DisplayAbsoluteFramesNotBuiltByPlaceholder`) to also directly build abspos
frames whose placeholder lived in a different continuation subtree. Skip
building those abspos frames when they are later traversed via their
placeholders.
Differential Revision: https://phabricator.services.mozilla.com/D294312
I looked at this because in bug 2014331 I need to mark more pseudos as
element-backed, and it's kinda silly the state our setup is in right
now.
This is all a somewhat historical mess, because in the old style system
pseudo-elements were just atoms, and we had that different types of atom
setup. The source of truth for these right now lives in a header macro
file, which isn't very flexible.
But now we have PseudoStyleType which represents both pseudos and anon
boxes, and is similar to the rust side PseudoElement enum.
Plus, the ::-moz-tree pseudo-elements are defined as anon boxes which
doesn't make any sense, so move them to pseudo-elements while at it.
Unify this in a similar way we treat CSS properties: Source of truth is
in pseudo_elements.toml / anon_boxes.toml, and we generate Rust and C++
as needed. This allows removing the nsStaticAtom subclass thing from
XPCOM, too.
This avoids some nasty duplication around which pseudos are pref-gated
and what not as well.
Differential Revision: https://phabricator.services.mozilla.com/D282076
I looked at this because in bug 2014331 I need to mark more pseudos as
element-backed, and it's kinda silly the state our setup is in right
now.
This is all a somewhat historical mess, because in the old style system
pseudo-elements were just atoms, and we had that different types of atom
setup. The source of truth for these right now lives in a header macro
file, which isn't very flexible.
But now we have PseudoStyleType which represents both pseudos and anon
boxes, and is similar to the rust side PseudoElement enum.
Plus, the ::-moz-tree pseudo-elements are defined as anon boxes which
doesn't make any sense, so move them to pseudo-elements while at it.
Unify this in a similar way we treat CSS properties: Source of truth is
in pseudo_elements.toml / anon_boxes.toml, and we generate Rust and C++
as needed. This allows removing the nsStaticAtom subclass thing from
XPCOM, too.
This avoids some nasty duplication around which pseudos are pref-gated
and what not as well.
Differential Revision: https://phabricator.services.mozilla.com/D282076
This patch also prevents triggering the following assertion when multicol
performs a measuring reflow in an incremental reflow scenario (Bug 2011462) with
`layout.abspos.fragmentainer-aware-positioning.enabled=true`.
```
###!!! ASSERTION: Shouldn't be incomplete if availableBSize is UNCONSTRAINED.:
'aReflowInput.AvailableBSize() != NS_UNCONSTRAINEDSIZE',
```
Differential Revision: https://phabricator.services.mozilla.com/D280856
See discussion in
https://phabricator.services.mozilla.com/D272401#inline-1485354
We seem to rely on the timing of overflow containers display items for e.g.
Pagination.
DisplayList will be sorted by z-index, but it's a stable sort that relies on
items being added in document order.
`out-of-flow-in-multicolumn-paint-order-003.html` fails due to us not
fragmenting grid items needs fragmentation.
Differential Revision: https://phabricator.services.mozilla.com/D281028
Mark abspos next-in-flows with the `NS_FRAME_IS_PUSHED_OUT_OF_FLOW` bit, and
adjust the display item generation code accordingly.
In Bug 1994346, pushed abspos first-in-flow will get the bit as well.
Differential Revision: https://phabricator.services.mozilla.com/D277138
We need a similar concept to mark an abspos frame that is pushed to a later
absolute-containing-block continuation. A frame is either a float or an abspos
and thus lives in a different frame child list, so the same bit can be used in
both scenarios without conflicts.
Differential Revision: https://phabricator.services.mozilla.com/D277137
This patch consists of several parts:
- Introduce `PushedAbsolute` frame list (i.e. `mPushedAbsoluteFrames`) in
AbsoluteContainingBlock. This list is a temporary list used during reflow,
to store abspos frames that need to be reflowed by the delegating frame's
next-in-flow.
- For an absolute containing block frame, ensure its continuations also have
absolute containing block.
- Ensure that the position of abspos continuation is correct by adjusting
border, available block-size, etc. in
`AbsoluteContainingBlock::ReflowAbsoluteFrame()`.
- Cache `layout.abspos.fragmentainer-aware-positioning.enabled` pref at the time
when `nsPresContext` is initialized such that the pref value is stable across
the lifetime of `nsPresContext`. This is to ensure the frame tree structure
hygiene.
Differential Revision: https://phabricator.services.mozilla.com/D272400
This patch consists of several parts:
- Introduce `PushedAbsolute` frame list (i.e. `mPushedAbsoluteFrames`) in
AbsoluteContainingBlock. This list is a temporary list used during reflow,
to store abspos frames that need to be reflowed by the delegating frame's
next-in-flow.
- For an absolute containing block frame, ensure its continuations also have
absolute containing block.
- Ensure that the position of abspos continuation is correct by adjusting
border, available block-size, etc. in
`AbsoluteContainingBlock::ReflowAbsoluteFrame()`.
- The change in `nsPresContext` is to force reconstruct frame tree when flipping
`layout.abspos.fragmentainer-aware-positioning.enabled` pref, to ensure frame
tree structure hygiene.
Differential Revision: https://phabricator.services.mozilla.com/D272400
`nsFloatingFirstLetterFrame` might lose its floating style after calling
`nsBlockFrame::UpdateFirstLetterStyle()`. I believe we have existing issues with
`::first-letter` and `::first-line` styling. It's probably related to bug 13610
or bug 548836.
Differential Revision: https://phabricator.services.mozilla.com/D272674
No need to reposition views during layout and so on, now that we don't
use views for either popups nor subdocuments.
No need for nsView to have parent / sibling / children either.
Differential Revision: https://phabricator.services.mozilla.com/D271205
The motivation is:
1. The `parentWM` is misleading, because the parent frame can create
`ReflowOutput` with this block frame's writing-mode, e.g. flex container did
this [1].
2. If this block frame is fragmented, to get the correct cb rect, we'll have to
apply the skip side for the border, which operates on this block's
writing-mode. This will be done in bug 1994083.
3. This does not change behavior, because we only use physical `containingBlock`
as the parameter to `AbsoluteContainingBlock::Reflow()`.
[1] https://searchfox.org/firefox-main/rev/931471037b8a4f16ce3ccfa864310540cac255c1/layout/generic/nsFlexContainerFrame.cpp#6431
Differential Revision: https://phabricator.services.mozilla.com/D272075
* At the beginning of `ReflowAbsoluteFrame()`, instead of printing the
delegating frame's computed size, it now prints the original containing block
rect, which is a more important information in abspos reflow.
* Use `MOZ_DEFINE_ENUM_TOSTRING_FUNC` to implement `LineReflowStatus` to string
helper.
* Add an indent when printing `LineReflowStatus`.
Differential Revision: https://phabricator.services.mozilla.com/D271734
This gets confusing because insets are computed against the padding rect, but
we store all frame rect information w.r.t. border rect - Add documentation to
make that fact more explicit.
Differential Revision: https://phabricator.services.mozilla.com/D271230
Most paths in the removed function returns the frame's padding
rect size. It doesn't seem that the single path that further
modifies the value is used.
This was added as Bug 282754, to account for scroll frames' behaviour
then.
Differential Revision: https://phabricator.services.mozilla.com/D270727
`DoRemoveFrame()` is used only to remove `Principal` and `NoReflowPrincipal`
child list, so this patch removes the dead code that handles removal of
out-of-flow frames and overflow containers.
Similarly, `DoRemoveOutOfFlowFrame()` is used only to remove float elements, so
rename it accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D270798
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
Ting-Yu Lin