This patch is generated via:
```
rg -l 'BlockReflowInput' layout/ | xargs sed -i 's/BlockReflowInput/BlockReflowState/g'
```
Manual fixes are in the next part.
Differential Revision: https://phabricator.services.mozilla.com/D139439
Its type is not `BlockReflowInput` but an ordinary `ReflowInput`. Rename it to
`mLineContainerRI` to match its accessor.
While I'm here, I change `mLineContainerRI` to be a reference since it cannot be
nullptr (see nsLineLayout's constructor); also, replace
`mLineContainerRI->mFrame` with `LineContainerFrame()`.
Differential Revision: https://phabricator.services.mozilla.com/D139438
The code at the end of ComputeFinalBSize() does not handle
"box-decoration-break:clone" and the cases where the block frame's reflow status
can change from incomplete to complete. This patch is an attempt to fix all the
possible scenarios.
Differential Revision: https://phabricator.services.mozilla.com/D138967
ComputeFinalBSize() gets most of its input parameters from BlockReflowInput's
members. Passing BlockReflowInput into it directly so that it can access more
precomputed data in BlockReflowInput such as `ContentBEnd()`.
This is a preparation for the next part that is going to rewrite a large portion
of ComputeFinalBSize().
Differential Revision: https://phabricator.services.mozilla.com/D138966
If a block container has box-decoration-break:clone, its block-end border and
padding (BP) are *usually* drawn at the block-end edge of the current
column/page. Thus, when computing the available block-size for its children, we
should subtract its block-end border BP from it.
When I claim the block-end BP are *usually* drawn at the block-end edge of the
column/page, the exception is when a block container with a definite block-size
runs out of its block-size in a column/page. In this case, the block-end BP is
drawn at the block-end edge of its content-box. This patch wires the effective
content-box block-size computed in nsBlockFrame::Reflow() into
BlockReflowInput's constructor, and we do not subtract its block-end border BP
from the `mContentArea.BSize(wm)` when this case happens.
`BlockReflowInput::ContentBSize()` is the correct available block-size to reflow
the children, precomputed in BlockReflowInput's constructor. See
https://searchfox.org/mozilla-central/rev/c12a59323ee46b29b90c9917a3a7a70ea714ffec/layout/generic/BlockReflowInput.cpp#118-126
The remove hunk was a hack, working only for ColumnSetWrapper with
`box-decoration-break:clone`. It's no longer needed.
Differential Revision: https://phabricator.services.mozilla.com/D138367
This causes (among other things) pages to be dark when using regular
windows system colors and forcing colors to "always", which is nice.
Differential Revision: https://phabricator.services.mozilla.com/D131165
This means nsBlockFrame::GetLineIterator is also infallible, so callers that know
they're dealing with an nsBlockFrame (not an arbitrary nsIFrame) don't need to
check for null.
Differential Revision: https://phabricator.services.mozilla.com/D126470
This should ensure the correct behavior when system colors are
semi-transparent, like on macOS on dark mode.
Testing this without hard-coding the system color seems hard (and I
think macOS on automation might not even hard native dark mode support
anyways).
In fact, if it did I think backplat-bg-image-006 would've caught it.
Differential Revision: https://phabricator.services.mozilla.com/D125475
Some of our GetNaturalBaselineBOffset implementations already have this; others
don't. But they all should have it, or else a caller might improperly query
their baseline and use it for layout despite the frame having 'contain:layout'.
Without this patch, the rest of this patch-stack makes us fail WPT test
contain-layout-suppress-baseline-002.html because we improperly honor the
baseline for the 'contain:layout' buttons at the top of the test.
Differential Revision: https://phabricator.services.mozilla.com/D121938
The issue is that we mark the second input as dirty when it gets the
reflow request (this is as expected), but then during multicol reflow
everything seems to go smoothly, but we hit this code:
https://searchfox.org/mozilla-central/rev/00977c4e37865a92f1c15572ae4aea90e934b25b/layout/generic/nsBlockFrame.cpp#3745
And bail out, leaving the line marked as not dirty, and as such the
stuff inside the page-break-inside: avoid dirty.
When it changes further, we think it's already dirty so don't bother
adding it to the dirty root list anymore and the text frame remains with
its original tiny width.
Differential Revision: https://phabricator.services.mozilla.com/D121869
This is more correct as it takes care about falling back to white as needed in
printing mode.
This is still not perfect because themed frames still get black-on-black text.
I'm not super-sure what's the right way to fix that, will
file a follow-up for that. In particular, when you have a themed
button, we use the system colors (i.e., black) to paint
it, but nsLayoutUtils::DarkenColorIfNeeded doesn't know it
and darkens the text color anyways.
Easiest fix is just not use the system colors when
printing, but that feels not-amazing...
Differential Revision: https://phabricator.services.mozilla.com/D118275
This is more correct as it takes care about falling back to white as needed in
printing mode.
This is still not perfect because themed frames still get black-on-black text.
I'm not super-sure what's the right way to fix that, will
file a follow-up for that. In particular, when you have a themed
button, we use the system colors (i.e., black) to paint
it, but nsLayoutUtils::DarkenColorIfNeeded doesn't know it
and darkens the text color anyways.
Easiest fix is just not use the system colors when
printing, but that feels not-amazing...
Differential Revision: https://phabricator.services.mozilla.com/D118275
When printing, we lighten backgrounds and darken colors, unless color-adjust:
exact is used. So with the current backplating logic we might end up using a dark
system color background for a backplate, but then darkening the test, ending up
in both more ink being used, and the text being unreadable.
We don't have a great test story for these but I can try...
Differential Revision: https://phabricator.services.mozilla.com/D117729
Before this patch, there's an edge case where we may drain a pushed float (with
a stale position), and then discover that it won't fit in the current block (so
we push it and leave its position untouched), but we still inadvertently
include its rect in the current block's overflow areas. This means we're
feeding stale/bogus position into the overflow areas, which can make them
unnecessarily huge.
This patch accounts for this by only considering overflow from floats that we
actually successfully placed, in ReflowPushedFloats.
(Also: this patch removes a stale bit of documentation about aLineLayout being
possibly-null in AddFloat. In actuality, AddFloat has a fatal assertion that
mandates that this arg is non-null.)
Differential Revision: https://phabricator.services.mozilla.com/D117218
The helper is going to be used in a later part.
I don't add the physical version ComputedPhysicalBorder() deliberately
because I don't want to promote the usage of physical coordinate.
Differential Revision: https://phabricator.services.mozilla.com/D114544
`aState.mBCoord` already includes block-start border and padding, so we
wrongly add the block-start border and padding twice when computing the
border-box content block-size. This patch fixed it, and rename
`contentBSize` variable to make it clearer.
Differential Revision: https://phabricator.services.mozilla.com/D112313
In Bug 1527949, we are going to add block-end padding of the block
container to aBEndEdgeOfChildren, so we need this patch in order to
query GetLogicalUsedPadding().
Differential Revision: https://phabricator.services.mozilla.com/D108889
Also, swap the argument order of aBEndEdgeOfChildren and aDisplay,
because I'm going to make ConsiderBlockEndEdgeOfChildren() a
nsBlockFrame method, and make its arguments the same order.
This patch shouldn't change the behavior.
Differential Revision: https://phabricator.services.mozilla.com/D108888
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
This patch adds the struct as a parameter to various functions.
The struct is cached in ReflowInput so that we don't need to pass it
down to the internal method where nsIFrame::ComputeSize() is called.
In the subsequent patches, we'll use it to revise the implementation of
flex container's flex base size resolution, and size overrides.
Differential Revision: https://phabricator.services.mozilla.com/D101793
This patch adds the struct as a parameter to various functions.
The struct is cached in ReflowInput so that we don't need to pass it
down to the internal method where nsIFrame::ComputeSize() is called.
In the subsequent patches, we'll use it to revise the implementation of
flex container's flex base size resolution, and size overrides.
Differential Revision: https://phabricator.services.mozilla.com/D101793
* Follow other flags' naming by putting "Is" at the beginning.
* Delete the accessor because we just access other flags directly.
Differential Revision: https://phabricator.services.mozilla.com/D102480
