This patch attempts another approach to avoid the O(n^2) time complexity of
updating the first-continuation cache when removing a frame's continuation chain
from front to back.
Assume F1, F2, and F3 are the first three continuations in the chain. When we
call `F2->SetPrevContinuation(nullptr)` to disconnect F1 from the chain, we now
purge the first-continuation cache for F2's next-continuations rather than
updating their cache value to F2.
At the time when we call `F3->SetPrevContinuation(nullptr)` to disconnect F2
from the chain, F3's next-continuations no longer have the cache. Therefor, we
don't need to do extra work to walk the next-continuations.
Because the first-continuation cache might not exist during the frame
destruction, this patch reintroduce the slow path to walk the prev-continuation
chain to reach the first-continuation.
Differential Revision: https://phabricator.services.mozilla.com/D214659
This patch is a revert of
https://hg.mozilla.org/mozilla-central/rev/8ea9b9da6922 because the correctness
assumption described in the commit message was wrong. Note that this patch does
not revert the documentation improvement for
`nsSplittableFrame::RemoveFromFlow()` because it is worth keeping.
During frame destruction, `nsBlockFrame::MarkIntrinsicISizesDirty()` can be
called and it accesses `FirstContinuation()`. Thus, it is not acceptable to
allow a stale first-continuation cache during frame destruction.
Differential Revision: https://phabricator.services.mozilla.com/D214658
The correctness assumption for this patch is that we destroy all frame
continuations when removing an element, so any stale first continuation cache
during frame destruction is acceptable.
Differential Revision: https://phabricator.services.mozilla.com/D213686
SetNextContinuation() and SetPrevContinuation() are almost always called
together when setting up a continuation link, but the callers don't call them in
particular order. We should unify them as one method so that it's more
ergonomics and robust, especially when we do more complex work such as caching
continuations. Same reason for SetNextInFlow() and SetPrevInFlow().
We choose to merge the SetPrevContinuation() code into SetNextContinuation() for
the symmetry of SetNextSibling(). (Yes, we don't have SetPrevSibling().)
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D197966
While I'm here, change `aFrame` to `mNextContinuation` so that it is clearer
that we are tweaking the bit on `mNextContinuation`.
Differential Revision: https://phabricator.services.mozilla.com/D197756
This is a preparation for Part 4 since a flex container frame needs to query a
flex item continuation's consumed block-size.
Differential Revision: https://phabricator.services.mozilla.com/D188529
This shouldn't change behavior, but it packs the two arguments to
DestroyFrom into a single thing, and makes nsIFrame::Destroy not so easy
to call without a previous context.
This is a prerequisite to pass aDestroyContext to various things that
right now just mint one, which can cause badness, see bug 1851787 and
related bugs.
It's also a bit nicer to add things there if we need to in the future.
Differential Revision: https://phabricator.services.mozilla.com/D187578
This shouldn't change behavior, but it packs the two arguments to
DestroyFrom into a single thing, and makes nsIFrame::Destroy not so easy
to call without a previous context.
This is a prerequisite to pass aDestroyContext to various things that
right now just mint one, which can cause badness, see bug 1851787 and
related bugs.
It's also a bit nicer to add things there if we need to in the future.
Differential Revision: https://phabricator.services.mozilla.com/D187578
This is helpful when we have extremely long continuation chains, to avoid having to
follow all the back-pointers to find the primary frame. By itself it makes little
difference to the testcase here, but is a basis for the patch that follows.
Differential Revision: https://phabricator.services.mozilla.com/D122998
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
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 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
`IS_TRUE_OVERFLOW_CONTAINER` is defined in nsContainerFrame.h, but is
already used in several places in nsIFrame. It really should be an
nsIFrame's method.
Differential Revision: https://phabricator.services.mozilla.com/D92007
To get the logical content size of a frame, some callers use
GetContentRectRelativeToSelf().Size() and then convert it to
LogicalRect. We really should generalize ContentBSize(), and provide
ContentSize() for such purpose.
Differential Revision: https://phabricator.services.mozilla.com/D68065
Simply remove "max-block-size: 100%" for -moz-column-set and
-moz-column-content breaks abspos-breaking-dynamic-{001,002,003}.html.
We need to reflow ColumnSetWrapper's children whenever
ColumnSetWrapper's block-size or max-block-size is changed because both
size affect the available block-size for ColumnSetWrapper's children.
We set `NS_FRAME_CONTAINS_RELATIVE_BSIZE` for ColumnSetWrapperFrame so
that it will set itself dirty in `selfDirty` in
`nsBlockFrame::ReflowDirtyLines`, and mark its lines dirty if
`aState.mReflowInput.IsBResize()` is true.
Differential Revision: https://phabricator.services.mozilla.com/D58731
Simply remove "max-block-size: 100%" for -moz-column-set and
-moz-column-content breaks abspos-breaking-dynamic-{001,002,003}.html.
We need to reflow ColumnSetWrapper's children whenever
ColumnSetWrapper's block-size or max-block-size is changed because both
size affect the available block-size for ColumnSetWrapper's children.
We set `NS_FRAME_CONTAINS_RELATIVE_BSIZE` for ColumnSetWrapperFrame so
that it will set itself dirty in `selfDirty` in
`nsBlockFrame::ReflowDirtyLines`, and mark its lines dirty if
`aState.mReflowInput.IsBResize()` is true.
Differential Revision: https://phabricator.services.mozilla.com/D58731
Frames split by column-span are linked together by non-fluid
continuations. We want GetLogicalSkipSides() to recognize that. The
documentation in nsIFrame::GetLogicalSkipSides() already
uses *continuation* rather than *in-flow*, so no need to adjust the
wording.
However, after patching GetLogicalSkipSides(), the first column-content
after a column-span split starts to skip the block-start side because it
has a previous continuation. We want the content in the first column to
consider applying its block-start margin. Hence the modification in
BlockReflowInput's constructor. (Note that the first column-content is
always a block-start margin-root, which is fixed in the previous part.)
This is necessary to avoid breaking
testing/web-platform/tests/css/css-multicol/multicol-span-all-margin-bottom-001.xht
In multicol-span-all-children-height-006.html, add "margin-top: 1em;" to
the container to expose the bug if we still check GetPrevInFlow() rather
than GetPrevContinuation() when computing applyBStartMargin in
nsBlockFrame::ReflowBlockFrame().
Differential Revision: https://phabricator.services.mozilla.com/D43905
Parts of nsFrame::Init or code called by it should be able to rely on the
invariant that, if the frame has the NS_FRAME_OUT_OF_FLOW bit, the first-in-flow
frame has a placeholder property.
Alternatively to this patch, the NS_FRAME_OUT_OF_FLOW frame bit could be
propagated later, as it used to be.
Differential Revision: https://phabricator.services.mozilla.com//D40815
Parts of nsFrame::Init or code called by it should be able to rely on the
invariant that, if the frame has the NS_FRAME_OUT_OF_FLOW bit, the first-in-flow
frame has a placeholder property.
Alternatively to this patch, the NS_FRAME_OUT_OF_FLOW frame bit could be
propagated later, as it used to be.
Differential Revision: https://phabricator.services.mozilla.com/D40815
In frame construction, a block can be split by column-spans into several
fragments and each of the fragments is chained together by non-fluid
continuations. Later in reflow, each fragment can create its own fluid
continuations due to reasons such as the constraint of its available
block-size.
The main idea of this patch is that we calculate the block's final
block-size by shrinkwrapping the children for every fragment except for
those fluid continuations after the final column-span. To do that, we
need to correctly tag each non-column-span-wrappers
nsIFrame::HasColumnSpanSiblings() except the last one.
We also need to modify nsSplittableFrame::ConsumedBSize() so that it
includes the block-size for both fluid and non-fluid continuations.
Differential Revision: https://phabricator.services.mozilla.com/D38124
Ting-Yu Lin