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
All the callers in nsBlockFrame call BlockReflowInput::ClearFloats(), I
don't feel we need to pass the DONT_CLEAR_PUSHED_FLOATS down to
nsFloatManager. Besides, I'll remove the flag in a later patch.
Differential Revision: https://phabricator.services.mozilla.com/D74537
We always define it to the same thing, and we're inconsistent in whether
we use `CPP_THROW_NEW` or `throw()`, so we might as well just use the
standard C++ thing and get rid of some baggage.
Differential Revision: https://phabricator.services.mozilla.com/D40425
--HG--
extra : moz-landing-system : lando
This enables destructors for tagged unions in cbindgen, implemented in:
* https://github.com/eqrion/cbindgen/pull/333
Which allow us to properly generate a destructor for the cbindgen-generated
StyleBasicShape (which now contains an OwnedSlice).
For now, we still use the glue code to go from Box<BasicShape> to
UniquePtr<BasicShape>. But that will change in the future when we generate even
more stuff and remove all the glue.
I could add support for copy-constructor generation to cbindgen for tagged
enums, but I'm not sure if it'll end up being needed, and copy-constructing
unions in C++ is always very tricky.
Differential Revision: https://phabricator.services.mozilla.com/D29769
--HG--
extra : moz-landing-system : lando
Per the discussion in:
https://groups.google.com/d/msg/mozilla.dev.platform/P79pwa9z5m8/iPYPAWPHCAAJ
They should be CamelCase, and that's what most of them already do. This converts
the rest, which are a few.
For the ones that already used `e` or `k` prefixes, I've mostly done:
for file in $(rg Type::e layout | cut -d : -f 1 | sort | uniq); do sed -i 's#Type::e#Type::#g' $file; done
For the ones that used uppercase, I've removed the prefix if it was already in
the type name, and turn them into CamelCase.
Depends on D28680
Differential Revision: https://phabricator.services.mozilla.com/D28681
--HG--
extra : moz-landing-system : lando
This patch changes remaining things under `layout/`. However, there are some
places which still need to use `nsIPresShell`. That will be fixed in a
follow up bug.
Differential Revision: https://phabricator.services.mozilla.com/D27477
--HG--
extra : moz-landing-system : lando
ShapeInfo and its derived classes are private to nsFloatManager, which don't
need to be in the header. Move them to cpp to make compile faster after
changing them.
MozReview-Commit-ID: MRkBGoqcPj
--HG--
extra : rebase_source : bc1de4269629f881e49af0d4faba89e8fbd4e460
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
After StyleBasicShape is set to StyleShapeSource, it's life cycle never go
beyond StyleShapeSource, so I make StyleBasicShape hold by a UniquePtr in
StyleShapeSource.
Also, replace all raw pointers to StyleBasicShape by UniquePtr in all APIs.
MozReview-Commit-ID: 1MfIFjP8TsQ
--HG--
extra : rebase_source : bdbbd47de57e0bc610e37913752ab8413f62588a
The <fill-rule> in the polygon() syntax is not handled because it doesn't
matter to shape-outside at all.
The reftests are numbered from 018 to avoid conflict with the w3c upstream
ones according to this list.
https://test.csswg.org/harness/results/css-shapes-1_dev/grouped/
Reftest 018 to 025 are under various writing-modes, 026 to 029 are testing
empty float area, 030 to 031 are testing polygon containing horizontal
lines.
MozReview-Commit-ID: FPUbMdZsvu6
Remove WritingMode parameter from LineRight() and LineLeft() in both
FloatInfo and ShapeInfo.
Bug 1316549 Part 3 added the parameter to compute the border radii under
writing-modes correctly. However, bug 1326407 Part 6 later made us cache
border radii, so the WritingMode parameter is no longer needed.
MozReview-Commit-ID: DFhm5d51OXJ
The reftests have passed
layout/reftests/w3c-css/submitted/check-for-references.sh.
MozReview-Commit-ID: JZk1fo8SxgV
--HG--
extra : rebase_source : 5010c7e32bfe383c855ea5899f84860c4c747658
The radii has been cached in the BoxShapeInfo in the previous part. Hence
the rename.
This class will be used to implement inset() in the next part, so the rect
stored isn't necessarily the rect of the <shape-box>. It could be the inset
rectangle. Therefore I rename mShapeBoxRect to mRect to avoid any confusion.
MozReview-Commit-ID: J0hpQDsbMyN
--HG--
extra : rebase_source : 76cf50e1819a586199934c29f46d467a1b86a9ec
The radii can be computed when creating BoxShapeInfo. No need to compute
them every time in the LineLeft() and LineRight().
MozReview-Commit-ID: GIDSLgickCT
--HG--
extra : rebase_source : 53bcb9bb89dc254119be00f6d091797bdbbec9af
Make the name and the order of arguments be consistent with the
ConvertPhysicalToLogical() method added in the previous part.
MozReview-Commit-ID: 1YARDzI3cyr
--HG--
extra : rebase_source : 41dfc4bf09610a5a38fed281d4a65157cf474503
The life cycle of nsFloatManager managed by mNew is same as
nsAutoFloatManager, which lives only in nsBlockFrame::Reflow(). Therefore,
other nsFloatManager pointers are all non-owning ref to the
nsAutoFloatManager::mNew.
MozReview-Commit-ID: B34BOcsjE2X
--HG--
extra : rebase_source : 49e4adaf31537b4003ee1a3db315f3e8bd8b1a7f
The difference between CircleShapeInfo's constructor and EllipseShapeInfo's
is the computation of the radii. Therefore, this patch creates a factory
function to distinguish that, so shape-outside: circle() could be
implemented by using EllipseShapeInfo.
MozReview-Commit-ID: 9ZBQu8zCSrM
Instead of manually adding (aLineLeft, aBlockStart) when creating a shape,
add Translate() to let the shapes implement their only way to move their
origin. FloatInfo could then move the shapes after they're created.
MozReview-Commit-ID: ApZBHnkng74
--HG--
extra : rebase_source : 10da425372e4e26b0da506059befc99e1c47a39d
circle() allows the user to define an empty flow area, so IsEmpty() needs to
be overridden.
The flow area defined by a shape needs to be clipped to the margin-box per
https://drafts.csswg.org/css-shapes/#relation-to-box-model-and-float-behavior
In the reftests, both clip-path and shape-outside uses the same value so
that it's easier to debug visually.
Add LogicalPoint::LineRelative() because we need to convert a point's I() to
the line-axis in nsFloatManager. LineRelative() differs from I() in all
'rtl' direction per
https://drafts.csswg.org/css-writing-modes-3/#logical-to-physical
MozReview-Commit-ID: FxQaFPrEQ73
--HG--
extra : rebase_source : 0d768002a38adbded2a0caa6d3e001eaaca3313d
Create ShapeInfo as a base class for implementing all the shapes. In this
design, we only need to create the correct subclass in FloatInfo's
constructor whenever shape-outside is used rather than manually branching on
StyleShapeSourceType and StyleBasicShape in all the methods like
LineRight(), LineLeft(), etc.
The concrete subclass of ShapeInfo could focus on implementing how its shape
influence the flow area by overriding the needed methods in ShapeInfo.
Move ComputeEllipseLineInterceptDiff() and XInterceptAtY() under the scope
of ShapeInfo so that they could be used by BoxShapeInfo and all the other
ShpapeInfo subclasses yet to come.
MozReview-Commit-ID: ETVc5FdGNha
--HG--
extra : rebase_source : 9a083ccd95fd7565112a45e30c15a91b97c7290f
Use move constructor for two reasons. 1) The copy constructor is needed only
when appending FloatInfo to mFloats, so using move constructor will likely
be more efficient if some of the member variables support move constructor.
2) Part 6 will added a UniquePtr member to FloatInfo, so using move
constructor becomes necessary.
Also change the return value of AddFloat() to void to simplify the code,
since all the other callers do not check the return value, and
BlockReflowInput::FloatAndPlaceFloat() only asserts in debug mode. I assume
it's safe to omit the OOM check.
MozReview-Commit-ID: GVbbsdBjr7b
--HG--
extra : rebase_source : e0f647e029278a5033bb9d6d780e73e32de460d3
circle() allows the user to define an empty flow area, so IsEmpty() needs to
be overridden.
The flow area defined by a shape needs to be clipped to the margin-box per
https://drafts.csswg.org/css-shapes/#relation-to-box-model-and-float-behavior
In the reftests, both clip-path and shape-outside uses the same value so
that it's easier to debug visually.
Add LogicalPoint::LineRelative() because we need to convert a point's I() to
the line-axis in nsFloatManager. LineRelative() differs from I() in all
'rtl' direction per
https://drafts.csswg.org/css-writing-modes-3/#logical-to-physical
MozReview-Commit-ID: FxQaFPrEQ73
--HG--
extra : rebase_source : 0d768002a38adbded2a0caa6d3e001eaaca3313d
Create ShapeInfo as a base class for implementing all the shapes. In this
design, we only need to create the correct subclass in FloatInfo's
constructor whenever shape-outside is used rather than manually branching on
StyleShapeSourceType and StyleBasicShape in all the methods like
LineRight(), LineLeft(), etc.
The concrete subclass of ShapeInfo could focus on implementing how its shape
influence the flow area by overriding the needed methods in ShapeInfo.
Move ComputeEllipseLineInterceptDiff() and XInterceptAtY() under the scope
of ShapeInfo so that they could be used by BoxShapeInfo and all the other
ShpapeInfo subclasses yet to come.
MozReview-Commit-ID: ETVc5FdGNha
--HG--
extra : rebase_source : 9a083ccd95fd7565112a45e30c15a91b97c7290f