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
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 allows supporting image-set(), etc, and simplifies the bullet frame
code significantly, too thanks to two changes:
* Instead of manually managing the image request, use the CSS image
loader, with the `REQUEST_REQUIRES_REFLOW` flag, to handle image
loads correctly. This didn't exist when this code was initially
implemented, but we can nicely use it now.
* Instead of re-implementing another WebRender command-builder thing,
we can just reuse the nsImageRenderer code.
Differential Revision: https://phabricator.services.mozilla.com/D100774
This allows supporting image-set(), etc, and simplifies the bullet frame
code significantly, too thanks to two changes:
* Instead of manually managing the image request, use the CSS image
loader, with the `REQUEST_REQUIRES_REFLOW` flag, to handle image
loads correctly. This didn't exist when this code was initially
implemented, but we can nicely use it now.
* Instead of re-implementing another WebRender command-builder thing,
we can just reuse the nsImageRenderer code.
Differential Revision: https://phabricator.services.mozilla.com/D100774
Making them non-overflow containers is valid but then we can't just
append them to mFrames since that'll put them on the last line which
may result in some lines in-between the pulled child and its
continuation. That violates the invariant that in-flow continuations
in the same parent must be on consecutive lines (unless they are
overflow containers in which case they need to be on the
[Excess]OverflowContainers lists).
(The crash happens because if we push the lines in-between the two
continuations to the OverflowLines, then we won't find the 2nd
continuation on the first line of OverflowLines.)
(Note also that this change triggers the assertion in
DrainExcessOverflowContainersList, and depends on bug 1680406
to fix that and merge the lists.)
Differential Revision: https://phabricator.services.mozilla.com/D99560
Making them non-overflow containers is valid but then we can't just
append them to mFrames since that'll put them on the last line which
may result in some lines in-between the pulled child and its
continuation. That violates the invariant that in-flow continuations
in the same parent must be on consecutive lines (unless they are
overflow containers in which case they need to be on the
[Excess]OverflowContainers lists).
(The crash happens because if we push the lines in-between the two
continuations to the OverflowLines, then we won't find the 2nd
continuation on the first line of OverflowLines.)
(Note also that this change triggers the assertion in
DrainExcessOverflowContainersList, and depends on bug 1680406
to fix that and merge the lists.)
Differential Revision: https://phabricator.services.mozilla.com/D99560
Precomputing the skipBEnd bit is odd / wrong. Using the PreReflow
version causes no regression, and allows us to simplify the code.
It also reverts the test annotations added to bug 1675376 which were
caused by the extra argument to GetLogicalSkipSides() somehow.
Differential Revision: https://phabricator.services.mozilla.com/D97418
Precomputing the skipBEnd bit is odd / wrong. Using the PreReflow
version causes no regression, and allows us to simplify the code.
It also reverts the test annotations added to bug 1675376 which were
caused by the extra argument to GetLogicalSkipSides() somehow.
Differential Revision: https://phabricator.services.mozilla.com/D97418
