DONTBUILD because this is comment-only.
This patch is just addressing a typo in a code comment that was left as a
review nit, which I forgot to address before landing.
Differential Revision: https://phabricator.services.mozilla.com/D45907
--HG--
extra : moz-landing-system : lando
Flex containers resolve a main-axis size for each of their flex items, and they
impose this size on the flex items by stomping on the items'
ReflowInput::ComputedISize() or ComputedBSize() data. For cases when we're
stomping on the flex item's block-axis, then this can make us improperly treat
this size as definite (i.e. use it for percent resolution).
The flexbox spec does call out some cases where the item's size *is* supposed
to be considered definite[1], but if we're not in one of those cases, we need
to be careful to treat the size as indefinite even though it's been resolved.
This patch achieves this by:
- adding a flag to FlexItem, which gets set in cases where we know we need to
treat the size as indefinite.
- adding a flag to ReflowInput, which gets set whenever a ComputedBSize is
imposed (if the FlexItem had its flag set).
- adding some code to the ReflowInput percent-resolution codepath to test for
this flag and skip past percent-resolution if it's set.
This patch makes us pass all of the existing testcases in the web-platform-test
"percentage-heights-003.html". This patch also adds a few more subtests
there to exercise cases where the flex container and item have orthogonal
writing-modes.
(Note the XXXdholbert comments in the patch about items being "fully
inflexible" in some cases in order to be treated as having a definite size.
If I were to address that comment here, then we would start failing the
web-platform-test "percentage-heights-005.html", which all browsers currently
pass[2]. Therefore, I'm not adding that restriction at this point.)
[1] https://drafts.csswg.org/css-flexbox/#definite-sizes
[2] https://wpt.fyi/results/css/css-flexbox/percentage-heights-005.html
Differential Revision: https://phabricator.services.mozilla.com/D43705
--HG--
extra : moz-landing-system : lando
This patch changes behavior only if column-span is enabled. It fixes a
lot of fuzzing test cases which will be added in the next part.
It changes the column balancing behavior in the following ways.
1) By using unconstrained block-size to measure the last column in the
first balancing iteration, we can guarantee that mKnownFeasibleBSize
has the correct feasible block-size.
2) Always reflow one more time if the content cannot fit in the
available content block-size. Due to 1), the content (last column)
always returns fully complete in the first balancing iteration even if
it's in an inner column with a constrained available block-size. We need
to reflow again to get the correct *incomplete* reflow status so that
the outer column can create next-in-flows for the inner column.
3) ColumnSet gives up balancing only when ColumnSetWrapper is running
out of block-size. When a ColumnSetWrapper has constrained block-size,
i.e. it's in a fragmentation context like pages or nested columns, we
prioritize fragmenting ColumnSetWrapper over creating overflow columns
within the nsColumnSet.
Differential Revision: https://phabricator.services.mozilla.com/D43128
--HG--
extra : moz-landing-system : lando
This depends on the line state stored in the previous patch, and will be
used in the following patch.
I'm passing this information through the reflow input here, rather than
doing an extra pass over the frame tree in the following patch, because
I believe it's substantially better for memory locality during reflow.
Differential Revision: https://phabricator.services.mozilla.com/D40275
--HG--
extra : moz-landing-system : lando
This is a potential fix that I thought it was worth doing rather than
implementing Blink's platform-dependent silliness. This ensures that the display
frame always has enough space to display itself.
Note that it may still get clipped, if there's no room for both the display
frame and the button.
Differential Revision: https://phabricator.services.mozilla.com/D37922
--HG--
extra : moz-landing-system : lando
This is a potential fix that I thought it was worth doing rather than
implementing Blink's platform-dependent silliness. This ensures that the display
frame always has enough space to display itself.
Note that it may still get clipped, if there's no room for both the display
frame and the button.
Differential Revision: https://phabricator.services.mozilla.com/D37922
--HG--
extra : moz-landing-system : lando
This reduces a bit of code complexity, fixes bugs where we weren't
reflowing enough, and optimizes additional cases that we couldn't
optimize in the past.
Co-authored-by: Chris Pearce <cpearce@mozilla.com>
Co-authored-by: L. David Baron <dbaron@dbaron.org>
Differential Revision: https://phabricator.services.mozilla.com/D37610
--HG--
extra : moz-landing-system : lando
This simplifies dealing with frames that are pushed/pulled between
continuations during reflow, allows us to avoid the complexity of the
fix to 1459937, and hopefully fixes some of the regressions from bug
1308876.
This disables the changes from bug 1459937 by commenting out a single
line in ReparentFrameInternal in nsBlockFrame.cpp, but all the added
code will be removed in the following patch.
Co-authored-by: Gerald Squelart <gsquelart@mozilla.com>
Co-authored-by: L. David Baron <dbaron@dbaron.org>
Depends on D36423
Differential Revision: https://phabricator.services.mozilla.com/D36424
--HG--
extra : moz-landing-system : lando
And move the useful bits of it somewhere else (ServoStyleConstInlines.h for the
inline function definitions, and nsFrame.cpp for the static assertions).
Differential Revision: https://phabricator.services.mozilla.com/D36120
And move the useful bits of it somewhere else (ServoStyleConstInlines.h for the
inline function definitions, and nsFrame.cpp for the static assertions).
Differential Revision: https://phabricator.services.mozilla.com/D36120
--HG--
extra : moz-landing-system : lando
There are some minor behavior changes come with this.
1) Change the default containing block size to (NS_UNCONSTRAINEDSIZE,
NS_UNCONSTRAINEDSIZE). I think this is more reasonable than (-1, -1).
2) mContainingBlockSize is used to cache only the block size passing
though constructor, Init(), or the invalid (-1, -1). This patch makes
it cache the value computed by ComputeContainingBlockRectangle().
Note that mContainingBlockSize is used only in
nsTableWrapperFrame::InitChildReflowInput() to set the inner table
frame's containing block to be the same as the outer table frame's.
We don't change this behavior by caching more. Because even if the
inner frame use the invalid cached (-1, -1) containing block size
from the outer reflow input, it still computes the block size again
in InitConstraints(). (Inner table's cb is the same as the outer
table's per InitCBReflowInput().)
Differential Revision: https://phabricator.services.mozilla.com/D28586
--HG--
extra : moz-landing-system : lando
This is a follow-up for Part 1. I find all the candidates by running the
following command under layout/, and manually replace them.
ag -A 1 reflow$ | ag -B 1 state
Differential Revision: https://phabricator.services.mozilla.com/D27162
--HG--
extra : moz-landing-system : lando
Really sorry for the size of the patch :(
Only intentional behavior change is in the uses of HasLengthAndPercentage(),
where it's easier to do the right thing. The checks that used to check for
(IsCalcUnit() && CalcHasPercentage()) are wrong since bug 957915.
Differential Revision: https://phabricator.services.mozilla.com/D19553
Before bug 1308876, child frames marked themselves as dirty during reflow if
their parent was dirty, too. After bug 1308876, the point where dirtiness is
being propagated to a frame's descendants has been shifted: Now, dirty parents
are responsible for marking all their children as dirty, too, when the parent
starts reflowing.
This means that if a frame wants to mark a whole subtree as dirty *during its
own* reflow, it's no longer sufficient to just mark the root of the subtree as
dirty and then rely on all further children marking themselves as dirty as well
when reflow reaches them.
The font inflation code is one such case. When the font inflation data on a font
inflation flow root has become dirty, or we're resizing the top-level frame
(which because of the effective container width clamping from bug 707855 can
affect the font inflation font size as well), we now need to explicitly mark all
affected children as dirty.
Differential Revision: https://phabricator.services.mozilla.com/D5577
--HG--
extra : moz-landing-system : lando
Before bug 1308876, child frames marked themselves as dirty during reflow if
their parent was dirty, too. After bug 1308876, the point where dirtiness is
being propagated to a frame's descendants has been shifted: Now, dirty parents
are responsible for marking all their children as dirty, too, when the parent
starts reflowing.
This means that if a frame wants to mark a whole subtree as dirty *during its
own* reflow, it's no longer sufficient to just mark the root of the subtree as
dirty and then rely on all further children marking themselves as dirty as well
when reflow reaches them.
The font inflation code is one such case. When the font inflation data on a font
inflation flow root has become dirty, or we're resizing the top-level frame
(which because of the effective container width clamping from bug 707855 can
affect the font inflation font size as well), we now need to explicitly mark all
affected children as dirty.
Differential Revision: https://phabricator.services.mozilla.com/D5577
--HG--
extra : moz-landing-system : lando
This patch doesn't change behavior; it's simply a rename.
I'm also fixing one mistyped mention of this variable in a comment in
nsFlexContainerFrame.cpp. (The comment had "Reflow" rather than "Height" in
its mention of this variable-name.)
MozReview-Commit-ID: KRW7FCVSlto
--HG--
extra : rebase_source : 2a27ea3bf9d3eabc437db398d24e374ce48ba677
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
Kagami Sascha Rosylight
Mats Palmgren
Ting-Yu Lin
Daniel Holbert
L. David Baron
Emilio Cobos Álvarez
Csoregi Natalia
Chris Pearce
Gerald Squelart
Cosmin Sabou
Cameron McCormack
Masayuki Nakano
Sylvestre Ledru
Dorel Luca
Jan Henning
Bogdan Tara
Noemi Erli
Jonathan Watt
Boris Zbarsky