After this patch, we still need nsFrameList::Enumerator to iterate
nsFrameList::Slice. We might enhance nsFrameList::Iterator to support Slice, but
I'll leave this for another day.
Differential Revision: https://phabricator.services.mozilla.com/D158809
Instead of digging into the first line-iterable frame. Digging into the
first line-iterable frame is bogus, because if there are multiple flex
items we might prevent moving through them properly (see test-case).
The flex implementation is nice and fairly complete, IMO. The grid one
is not, but the resulting behavior is nicer than the behavior before
this patch, seems reasonable, and matches Chrome in my testing.
In Searchfox, the behavior is even funnier because user-select: none is
involved, but that predates the regression.
Differential Revision: https://phabricator.services.mozilla.com/D158086
Some anonymous children are important for properly sizing their parents
even when those parents hide content with `content-visibility`. This is
shown by regressions in the proper layout of some form elements with
`content-visibility`.
This change introduces a more conservative approach for avoiding layout
of hidden content. Instead of leaving all children dirty during reflow,
reflow anonymous frames (and nsComboboxDisplayFrame, a specialized kind
of anonymous frame). This change means that frames may only lay out some
of their children, so it must introduce some more changes to assumptions
during line layout.
In addition, this change renames `content-visibility` related methods in
nsIFrame in order to make it more obvious what they do.
Differential Revision: https://phabricator.services.mozilla.com/D157306
Some anonymous children are important for properly sizing their parents
even when those parents hide content with `content-visibility`. This is
shown by regressions in the proper layout of some form elements with
`content-visibility`.
This change introduces a more conservative approach for avoiding layout
of hidden content. Instead of leaving all children dirty during reflow,
reflow anonymous frames (and nsComboboxDisplayFrame, a specialized kind
of anonymous frame). This change means that frames may only lay out some
of their children, so it must introduce some more changes to assumptions
during line layout.
In addition, this change renames `content-visibility` related methods in
nsIFrame in order to make it more obvious what they do.
Differential Revision: https://phabricator.services.mozilla.com/D157306
Some anonymous children are important for properly sizing their parents
even when those parents hide content with `content-visibility`. This is
shown by regressions in the proper layout of some form elements with
`content-visibility`.
This change introduces a more conservative approach for avoiding layout
of hidden content. Instead of leaving all children dirty during reflow,
reflow anonymous frames (and nsComboboxDisplayFrame, a specialized kind
of anonymous frame). This change means that frames may only lay out some
of their children, so it must introduce some more changes to assumptions
during line layout.
In addition, this change renames `content-visibility` related methods in
nsIFrame in order to make it more obvious what they do.
Differential Revision: https://phabricator.services.mozilla.com/D156473
Use a more precise, grid-specific flag to avoid applying grid stretching
etc, and pass an unconstrained block size instead for baseline alignment
measuring, which will cause us to interpret relative sizes as auto.
This shouldn't cause any behavior change, but is a prerequisite
necessary for bug 1609403 (where we don't always want definite sizes
being ignored in measuring reflows for baseline alignment). It's also a
bit clearer, IMO.
Differential Revision: https://phabricator.services.mozilla.com/D155178
When block size is initially indefinite but later was determined by the contain intrinsic
size, we calculate the repeat fill count using the contain intrinsic block size.
Differential Revision: https://phabricator.services.mozilla.com/D153933
When block size is initially indefinite but later was determined by the contain intrinsic
size, we calculate the track sizes using the contain intrinsic block size.
Differential Revision: https://phabricator.services.mozilla.com/D153623
When block size is initially indefinite but later was determined by the contain intrinsic
size, we calculate the track sizes using the contain intrinsic block size.
Differential Revision: https://phabricator.services.mozilla.com/D153623
When block size is initially indefinite but later was determined by the contain intrinsic
size, we calculate the track sizes using the contain intrinsic block size.
Differential Revision: https://phabricator.services.mozilla.com/D153623
When block size is initially indefinite but later was determined by the contain intrinsic
size, we calculate the track sizes using the contain intrinsic block size.
Differential Revision: https://phabricator.services.mozilla.com/D153611
Some tests are still failing but I think it's due to bug 1481876: after
determining the block size of the grid container, the rows that depend
on it (like percentages or fr units) are not recomputed.
Also, 'contain-intrinsic-size: none' behaves as 0, ignoring the track
sizes and gaps, but that's bug 1488878.
Differential Revision: https://phabricator.services.mozilla.com/D153279
In the description of the mTruncated bit, its purpose is the same as calling
SetInlineLineBreakBeforeAndReset(). We've removed all its usages in previous
patches, so the bit is no longer needed.
Differential Revision: https://phabricator.services.mozilla.com/D151461
The optimized code path for nested grid layout should only set the
BSize of the child frames, since this is what the optimization is
for.
Without the change, the ISize is always going to be set to 0 for
child frames which may break the layout. Sometimes, it is not
an issue because the ISize of the grid area gets updated, so
the cached measurement becomes invalid, and the ISize of the child
frame gets set to the correct one again.
Differential Revision: https://phabricator.services.mozilla.com/D130828
This patch updated the grid container's scrollable overflow areas to
match the spec. This also fixed Bug 1532383 - include space in empty
explicit grid tracks in the scrollable overflow area.
Note: this patch can make overflow areas reported by grid container
overflow off the top or left, but the overflow areas won't be scrollable
because they are clipped once `nsHTMLScrollFrame` calls
`nsLayoutUtils::GetScrolledRect()`.
Differential Revision: https://phabricator.services.mozilla.com/D111995
This patch updated the grid container's scrollable overflow areas to
match the spec. This also fixed Bug 1532383 - include space in empty
explicit grid tracks in the scrollable overflow area.
Note: this patch can make overflow areas reported by grid container
overflow off the top or left, but the overflow areas won't be scrollable
because they are clipped once `nsHTMLScrollFrame` calls
`nsLayoutUtils::GetScrolledRect()`.
Differential Revision: https://phabricator.services.mozilla.com/D111995
When `aGridFrame.mFrame` is a scroll frame, the inner scrolled frame
`subgridFrame` only has padding, but no margin nor border. We should add
margin and border from the outer scroll frame to `mMarginBorderPadding`
so that the grid area of the subgrid is computed correctly.
Differential Revision: https://phabricator.services.mozilla.com/D114546
SizeComputationInput's logical margin and border&padding getters accept
arbitrary writing mode, so we can operate on `cbWM` directly without
using physical coordinates.
This patch is a preparation of the next part, and it shouldn't change
the behavior.
Differential Revision: https://phabricator.services.mozilla.com/D114545
Note that this patch only transforms the use of the nsDataHashtable type alias
to a directly equivalent use of nsTHashMap. It does not change the specification
of the hash key type to make use of the key class deduction that nsTHashMap
allows for in some cases. That can be done in a separate step, but requires more
attention.
Differential Revision: https://phabricator.services.mozilla.com/D106008
I assume nsIFrame::IsAbsolutelyPositioned()'s callers really want to
check whether a frame is a real abspos frame, not just check a frame has
a abspos style. This could potentially change the behavior, but I feel
its the right thing to do.
Differential Revision: https://phabricator.services.mozilla.com/D106580
This will prevent growing them when introducing fit-content(<length>).
This can _almost_ be derived, if it wasn't because of the quirky stuff.
I think the macro is probably good enough for now but let me know if you
disagree.
Differential Revision: https://phabricator.services.mozilla.com/D106713
This will prevent growing them when introducing fit-content(<length>).
This can _almost_ be derived, if it wasn't because of the quirky stuff.
I think the macro is probably good enough for now but let me know if you
disagree.
Differential Revision: https://phabricator.services.mozilla.com/D106713
