break-before/after: page|column seem harder because you need to deal
with nested breaks, I think, but this should be straight-forward.
Differential Revision: https://phabricator.services.mozilla.com/D121206
break-before/after: page|column seem harder because you need to deal
with nested breaks, I think, but this should be straight-forward.
Differential Revision: https://phabricator.services.mozilla.com/D121206
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
It's straightforward to determine which writing mode is required to pass
to ComputedLogicalMargin() by looking at any subsequent method called on
the margin.
For example, if we see
```
ComputedLogicalMargin().BStartEnd(wm);
```
the writing mode needed to pass to `ComputedLogicalMargin()` is `wm`.
Differential Revision: https://phabricator.services.mozilla.com/D95661
nsColumnSetFrame won't have any border and padding because it's an inner
frame under ColumnSetWrapper. We've already asserted this fact at the
beginning of nsColumnSetFrame::Reflow().
This change shouldn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D93626
It's useful to use `std::move()` to indicate the frames' ownership in one list
is transferred to the another list.
For a frame list managed by AutoFrameListPtr, after moving its frames to
another list, it can be automatically deleted when it is going out of
scope.
Differential Revision: https://phabricator.services.mozilla.com/D88455
I feel skipIncremental is hard to reasoning. It's easier to list all the
possible reasons that the child needs to be reflowed again.
Differential Revision: https://phabricator.services.mozilla.com/D88699
Rename so that its naming is consistent with ReflowConfig::mColISize,
and to avoid confusion with ColumnBalanceData::mMaxBSize.
Differential Revision: https://phabricator.services.mozilla.com/D88697
The gist of this patch is: once the feasible and infeasible block-size
is within one device pixel, we choose nextGuess to be the greatest
multiple of one device pixel below or equal to the feasible block-size.
If this nextGuess is infeasible, we will reflow children one last time
by using the last feasible block-size and done with the balancing.
Differential Revision: https://phabricator.services.mozilla.com/D83732
Here's an example that can break the loop at the first iteration.
<div style="column-count:2; height:100px"><img src="" style="height:500px">
Differential Revision: https://phabricator.services.mozilla.com/D83731
This is a straightforward conversion except that
`NS_SUBTREE_DIRTY(this)` can be written terser as `IsSubtreeDirty()`.
Differential Revision: https://phabricator.services.mozilla.com/D82811
In FindBestBalanceBSize(), suppose we have aUnboundedLastColumn equals
to true, and the measuring reflow of all the columns is feasible. This
setting represents the most common scenario of multi-column layout as
the multi-column footnote on Wikipedia.
We used to use 600 as the extra block-size added to the estimate column
block-size. However, if the first guess of the column block-size, say
G1, is infeasible, the feasible block-size is still bound to the sum of
all columns S. That leaves us a massive range between G1 and S to
search.
We don't want to use a larger fixed extra block-size. Although it can
reduce the possibility of failing the first guess, but for cases where a
smaller extra block-size is sufficient, it increases the search range
and the iteration number before the binary search converges.
Instead, we can spend the first few iterations doubling the extra
block-size E added to the estimate column block-size until we find the
first feasible block-size. This gives us a smaller upper bound S / N +
E, where N is the number of columns.
Differential Revision: https://phabricator.services.mozilla.com/D80571
The motivation is to replace mFrames.GetLength() in
FindBestBalanceBSize() since it is O(N), where N is the number of
columns.
Also, counting the column number from 1 so that it matches mUsedColCount
without needing to subtract 1 at some places.
Differential Revision: https://phabricator.services.mozilla.com/D80569
* childContentBEnd: this value can be larger than
kidDesiredSize.BSize(wm) if -moz-column-content anonymous blocks has a
child which is overflow-incomplete.
* mLastBSize: last column's block-size is important in column balancing
algorithm because it sets mKnownInfeasibleBSize when a balancing
iteration is feasible.
* The iteration count in column balancing. This is an easy way to
observe column balancing performance.
Differential Revision: https://phabricator.services.mozilla.com/D80568
Checking ColumnSet's available block-size [1] makes no sense nowadays
because ColumnSet is an inner frame under ColumnSetWrapper. We should
check ColumnSetWrapper's available block-size instead.
Also, bump assertions count for 1015844.html on Android, which is a
crashtest having multicols.
[1] The comment was also misleading, which said it was checking
ColumnSet's "block-size", but it actually was checking available
block-size.
Differential Revision: https://phabricator.services.mozilla.com/D63385
--HG--
extra : moz-landing-system : lando
Checking ColumnSet's available block-size [1] makes no sense nowadays
because ColumnSet is an inner frame under ColumnSetWrapper. We should
check ColumnSetWrapper's available block-size instead.
[1] The comment was also misleading, which said it was checking
ColumnSet's "block-size", but it actually was checking available
block-size.
Differential Revision: https://phabricator.services.mozilla.com/D63385
--HG--
extra : moz-landing-system : lando
They were used when nsColumnSetFrame was still a column container, but
are not used today.
Differential Revision: https://phabricator.services.mozilla.com/D64647
--HG--
extra : moz-landing-system : lando
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
The trickier part is that we represent -moz-image-rect as a Rect() type instead
of image with non-null clip-rect. So we need to add a bit of code to
distinguish "image request types" from other types of images.
But it's not too annoying, and we need to do the same for fancier images like
image-set and such whenever we implement it, so seems nice to get rid of
most explicit usages of nsStyleImage::GetType().
Differential Revision: https://phabricator.services.mozilla.com/D62164
--HG--
extra : moz-landing-system : lando
Nowadays, ColumnSetFrame is an inner frame under ColumnSetWrapperFrame.
It always has "block-size: auto", so `aReflowInput.ComputedBSize()`
always equals to NS_UNCONSTRAINEDSIZE.
Also, -moz-column-content no longer has "max-block-size: 100%", so
NS_FRAME_CONTAINS_RELATIVE_BSIZE can never be set on ColumnSetFrame when
constructing ReflowInputs for ColumnSetFrame's children in
`ReflowInput::InitResizeFlags`. Removing the bit is not needed, either.
Differential Revision: https://phabricator.services.mozilla.com/D58732
--HG--
extra : moz-landing-system : lando
Nowadays, ColumnSetFrame is an inner frame under ColumnSetWrapperFrame.
It always has "block-size: auto", so `aReflowInput.ComputedBSize()`
always equals to NS_UNCONSTRAINEDSIZE.
Also, -moz-column-content no longer has "max-block-size: 100%", so
NS_FRAME_CONTAINS_RELATIVE_BSIZE can never be set on ColumnSetFrame when
constructing ReflowInputs for ColumnSetFrame's children in
`ReflowInput::InitResizeFlags`. Removing the bit is not needed, either.
Differential Revision: https://phabricator.services.mozilla.com/D58732
--HG--
extra : moz-landing-system : lando
The issues fall into these categories:
- Files that used StaticPrefs::layout_XYZ() API or gfxVars::XYZ that needed an
include. (Addressed by adding the missing include.)
- Files that use mozilla::dom::XYZ or mozilla::gfx::XYZ without qualifying the
namespace & without a 'using' decl. (Addressed by adding "using".)
- A few other includes for types/inlines that were used without their header.
Depends on D50162
Differential Revision: https://phabricator.services.mozilla.com/D50163
--HG--
extra : moz-landing-system : lando
That is, for the multicol container of depth two and more, we lay them
out by using "column-fill:auto" and "column-count:1".
I've check bug 725376 comment 9 for the previous approaches. Thanks to
bug 1555818, this solution is feasible because the fragmentation with
"column-fill:auto" is now possible.
Differential Revision: https://phabricator.services.mozilla.com/D47011
--HG--
extra : moz-landing-system : lando
That is, for the multicol container of depth two and more, we lay them
out by using "column-fill:auto" and "column-count:1".
I've check bug 725376 comment 9 for the previous approaches. Thanks to
bug 1555818, this solution is feasible because the fragmentation with
"column-fill:auto" is now possible.
Differential Revision: https://phabricator.services.mozilla.com/D47011
--HG--
extra : moz-landing-system : lando
This patch makes fragmentation in "column-fill:auto" mode possible.
Note that we only bail out of creating more column contents when
"column-fill:auto" mode is set from the styles, i.e. when mForceAuto is
false. That is because when mForceAuto is true, we usually in the case
where we have gave up balancing, and we really want to create overflow
columns.
Note: without `!aConfig.mForceAuto` check, 673770.html can generated
assertions, and the frame tree contains dangling Overflow-lines and
ExcessOverflowContainersList.
Differential Revision: https://phabricator.services.mozilla.com/D47005
--HG--
extra : moz-landing-system : lando
mUsedColCount is used in balancing mode to check whether we have created
the maximum number of columns when the content cannot fit. Similarly,
mUsedColCount can also be useful in "column-fill:auto" mode to improve
the fragmentation story in the next patch.
This patch doesn't change the behavior (yet).
Differential Revision: https://phabricator.services.mozilla.com/D47004
--HG--
extra : moz-landing-system : lando
In next patch, this variable won't be set to INT32_MAX in
"column-fill:auto" mode, and it will be used in Part 4. Hence the
rename.
Differential Revision: https://phabricator.services.mozilla.com/D47003
--HG--
extra : moz-landing-system : lando
The associated if-block has a "break" statement at the end of the scope
to break the while-loop, making the else-block redundant.
Differential Revision: https://phabricator.services.mozilla.com/D47002
--HG--
extra : moz-landing-system : lando
Fragmentation spec already has a paragraph describing this behavior.
DONTBUILD because this is a comment only change.
Differential Revision: https://phabricator.services.mozilla.com/D46691
--HG--
extra : moz-landing-system : lando
Since column-contents' positions are moved, we need to fix ColumnSet's
overflow areas as well.
Differential Revision: https://phabricator.services.mozilla.com/D44279
--HG--
extra : moz-landing-system : lando
Emilio Cobos Álvarez
Noemi Erli
Ting-Yu Lin
Kagami Sascha Rosylight
Csoregi Natalia
Simon Giesecke
Dorel Luca
Bogdan Tara
James Hooks
Daniel Holbert
Coroiu Cristina