This effectively makes ClearFloat() act like it always has
DONT_CLEAR_PUSHED_FLOATS. Thus, the flag is no longer needed.
We need to add an early return condition when the block cannot fit in
ReflowBlockFrame(). Because we now don't return nscoord_MAX when floats
are pushed or split, the `availSpace.BSize(wm)` might equal to zero
rather than negative in this case. It's needed by
testing/web-platform/tests/css/CSS2/floats-clear/floats-clear-multicol-003.html
and layout/reftests/pagination/float-clear-003-print.html
Differential Revision: https://phabricator.services.mozilla.com/D74540
This change doesn't change the behavior yet. It just changes all the
callers by having them catch the ClearFloatsResults.
Some of the callers will be revised in next patch by utilizing the
returned results. Some of the return values are not being used, and may
produce warnings, they will be suppressed in the next patch, too.
Differential Revision: https://phabricator.services.mozilla.com/D74538
ContentBEnd() is equivalent to mBEndEdge except when ContentBSize() is
unconstrained because ContentBEnd() can overflow. However, according to
ContentBEnd()'s documentation, the user shouldn't use ContentBEnd() when
ContentBSize() is constrained, so I add an assertion in ContentBEnd() as
a reminder.
Differential Revision: https://phabricator.services.mozilla.com/D68624
--HG--
extra : moz-landing-system : lando
The flag's original form `mUnconstrainedHeight` was added in
nsBlockReflowState.h in
e580331b37
Nowadays, we often check available block-size in reflow directly in nsBlockFrame.
Differential Revision: https://phabricator.services.mozilla.com/D42733
--HG--
extra : moz-landing-system : lando
We always pass consumed block-size into BlockReflowInput's constructor
in nsBlockFrame::Reflow(). By making mConsumedBSize a constant, its
assessor method becomes redundant.
Update the documentation to reflect the reality that ConsumedBSize()
accumulates content block-size from all previous *continuations*, which
was done in Bug 1506293 Part 2.
Differential Revision: https://phabricator.services.mozilla.com/D41906
--HG--
extra : moz-landing-system : lando
GetAvailableSpace was renamed to GetFloatAvailableSpace in bug 25888.
DONTBUILD because this is a comment-only change.
Differential Revision: https://phabricator.services.mozilla.com/D30581
--HG--
extra : moz-landing-system : lando
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: EuRsDue63tK
--HG--
extra : rebase_source : 3356d4b80ff6213935192e87cdbc9103fec6084c
From the "NS_ASSERTION(mFloatManager)" statement in BlockReflowInput's
constructor, we know that BlockReflowInput's mFloatManager is always valid
and equals to aReflowInput.mFloatManager. Therefore, we could just use
ReflowInput's float manager in BlockReflowInput.
Due to the removal of BlockReflowInput's mFloatManager, the logic which
resets mFloatManager near the end of nsBlockFrame::Reflow() is removed as
well. It's safe because beyond that point, no other logic involves floats,
and |state| (i.e. BlockReflowInput) lives only on the stack.
MozReview-Commit-ID: 3dwXMnWkEI6
--HG--
extra : rebase_source : 7f9af1af10fd54456450b23bc0004dd5f15db4e4
Per spec, float positioning and stacking is not affected by defining a float
area with a shape.
https://drafts.csswg.org/css-shapes/#relation-to-box-model-and-float-behavior
So all the call sites of GetFloatAvailableSpace() related to adding a
float are replaced by GetFloatAvailableSpaceForPlacingFloat().
<shape-box> with border-radius will be implemented in next part.
MozReview-Commit-ID: 1RXEeXDhdWo
--HG--
extra : rebase_source : 42cdb0c81b16168e4e30ee2261ceccb562e278cf
In nsBlockFrame::PlaceLine(), we query the float available space by
using the line's BSize(), which may cause the line to reflow again due
to available space shrunk.
The first issue lies in the second reflow. That is, we do not leverage
the line's BSize() computed in the first reflow to query the float
available space when updating the inline reflow engine in
BlockReflowInput::AddFloat(). So some tall inline elements could still
overlap the floats as in the first reflow.
To solve this, we cache current line's BSize so that it could be
used to update the inline reflow engine when redo the line.
Another issue is in nsBlockFrame::PlaceLine(). When determined whether
the available space is shrunk, we use the float manager's state *before*
placing the line. So if current line has floats, they're not considered.
To solve this, we use the current set of floats to get the float available
space for comparison, and leave the original aFloatAvailableSpace to provide
the information when redoing the line.
MozReview-Commit-ID: GqqNlphgxYS
--HG--
extra : rebase_source : e2c64ab1ac363c7a08e532dc043bee69d6455049
After using enum class, a switch-case warning in CombineBreakType is caught.
This is one of such kind safty checks that we would like to gain.
Fix it by adding default case for switch-case in CombineBreakType.
MozReview-Commit-ID: BdS3LPN6qzX
--HG--
extra : rebase_source : 17f24a0d482ed6eb51b23e6942d0ac1c87375e0b