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
That avoids going all the way to the first continuation to call ResolveBidi on
it. This shaves a bunch of time when there are a lot of pages.
This is more problematic than it seems specially when there's no bidi, because
in the "bidi not enabled" case we never remove the flag, which is bad. When
bidi is actually enabled we usually have done the resolution already.
Differential Revision: https://phabricator.services.mozilla.com/D97358
This removes virtually all the time under ConsumedBSize. See the comment for
what ensures the correctness of the cache: Basically, we refresh the cache for
a frame continuation every time we reflow it, which means that when next
continuations go look for it it should be up-to-date (we rely on that already
because we're looking at the content rect).
Differential Revision: https://phabricator.services.mozilla.com/D97357
That avoids going all the way to the first continuation to call ResolveBidi on
it. This shaves a bunch of time when there are a lot of pages.
This is more problematic than it seems specially when there's no bidi, because
in the "bidi not enabled" case we never remove the flag, which is bad. When
bidi is actually enabled we usually have done the resolution already.
Differential Revision: https://phabricator.services.mozilla.com/D97358
This removes virtually all the time under ConsumedBSize. See the comment for
what ensures the correctness of the cache: Basically, we refresh the cache for
a frame continuation every time we reflow it, which means that when next
continuations go look for it it should be up-to-date (we rely on that already
because we're looking at the content rect).
Differential Revision: https://phabricator.services.mozilla.com/D97357
This patch is generated via the rename functionality in my editor; add
`mozilla::` prefix to `OverflowAreas` in headers; and remove the
`OverflowType` alias added in Part 1.
Differential Revision: https://phabricator.services.mozilla.com/D97235
