The previous commit removed the dependence on the discriminant value, so we
don't need to keep discriminants different from text-align anymore.
Differential Revision: https://phabricator.services.mozilla.com/D29361
--HG--
extra : moz-landing-system : lando
We have a better type to represent "a coord or nothing", and that's Maybe.
This code is shorter, and I think reads generally better / is less easy to
misuse.
I wrote this on top of bug 1547126 so there shouldn't be conflicts.
Differential Revision: https://phabricator.services.mozilla.com/D28921
--HG--
extra : moz-landing-system : lando
We do want to record soft break opportunity after a frame whose content can't
be part of the existing in-flow text run, since this normally should be a text run
boundary. However, though an out-of-flow frame can't be part of the existing
in-flow text run, it also doesn't break it either. In fact, the texts after the
out-of-flow frames are able to continue the existing in-flow text run. So,
introducing a line-break-after opportunity in this case may cause an unexpected
line break for every out-of-flow frame.
In this patch, we add a condition to prevent us from recording soft break
opportunities for out-of-flow frames.
Differential Revision: https://phabricator.services.mozilla.com/D28625
--HG--
extra : moz-landing-system : lando
We do want to record soft break opportunity after a frame whose content can't
be part of the existing in-flow text run, since this normally should be a text run
boundary. However, though an out-of-flow frame can't be part of the existing
in-flow text run, it also doesn't break it either. In fact, the texts after the
out-of-flow frames are able to continue the existing in-flow text run. So,
introducing a line-break-after opportunity in this case may cause an unexpected
line break for every out-of-flow frame.
In this patch, we add a condition to prevent us from recording soft break
opportunities for out-of-flow frames.
Differential Revision: https://phabricator.services.mozilla.com/D28625
--HG--
extra : moz-landing-system : lando
This also adopts the resolution from [1] while at it, making letter-spacing
compute to a length, serializing 0 to normal rather than keeping normal in the
computed value, which matches every other engine.
This removes the SMIL tests for percentages from letter-spacing since
letter-spacing does in fact not support percentages, so they were passing just
by chance.
[1]: https://github.com/w3c/csswg-drafts/issues/1484
Differential Revision: https://phabricator.services.mozilla.com/D21850
--HG--
extra : moz-landing-system : lando
Only nsBlockFrame and its subclasses recognize the nsIFrame::eBlockFrame
flag, so we can replace the usage of the flag with either
nsIFrame::IsBlockFrameOrSubclass() or a do_QueryFrame().
Differential Revision: https://phabricator.services.mozilla.com/D20542
--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
Also for the intersection observer root margin, since it was easier to fix it
up and clean it up than not doing it.
This is the first big step to get rid of nscoord. It duplicates a bit of logic
in nsLayoutUtils since for now max/min-width/height are still represented with
nsStyleCoord, but I think I prefer to land this incrementally.
I didn't add helpers for the physical accessors of the style rect sides that
nsStyleSides has (top/bottom/left/right) since I think we generally should
encourage the logical versions, but let me know if you want me to do that.
Differential Revision: https://phabricator.services.mozilla.com/D17739
Many of the modifications are guarded by #ifdefs. I verify them locally
by manually define them in nsBlockDebugFlags.h and nsLinelayout.cpp.
Note that I replace "mFrame" with "frame" in lines guarded by
NOISY_BLOCK_DIR_MARGINS in nsBlockFrame.cpp because they were
incorrectly renamed in Bug 1277129 Part 6a.
https://hg.mozilla.org/mozilla-central/rev/a70b04f074fc
Differential Revision: https://phabricator.services.mozilla.com/D17733
--HG--
extra : moz-landing-system : lando
1. Drop {Width|MinWidth|MaxWidh}DependsOnContainer() and
{Height|MinHeight|MaxHeight}DependsOnContainer() because they are bogus
after introducing the writing mode. Dropping these functions needs
update nsLineLayout because it is the only one who still use
these functions.
2. There are still some potential assertions and bugs on handling keywords
in the block size, so we should update them as well.
Depends on D9438
Differential Revision: https://phabricator.services.mozilla.com/D9439
--HG--
extra : moz-landing-system : lando
To avoid its deferred reflow potentially killing continuations that are parented
to the parent of the letter frame.
This rolls back to the behavior previous to bug 488725 just for this case, until
we fix it properly in bug 1490281. This also fixes bug 1489863.
Differential Revision: https://phabricator.services.mozilla.com/D5521
Bug 1478178 regressed this case because bullet frame is the last frame
added to line layout, rather than the first, so when we try to apply
justification, we end up giving it the accumulated offset of the whole
line.
Bullet frame has to be added after other frames in the line have been
placed, because its presence may depend on whether the line is empty.
However, bullet frame is logically the first frame in a line and
appending it to the end is somewhat counter-intuitive.
Thus, this patch tries to fix the issue via prepending bullet frame in
line layout, so that the order of frames there can be more reliable.
Differential Revision: https://phabricator.services.mozilla.com/D3760
--HG--
extra : moz-landing-system : lando
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
This avoids conflicts with mozilla::dom::FrameType.
MozReview-Commit-ID: 7aEMbHRaTFk
--HG--
extra : rebase_source : 2d01321f5ce0ec8c0e3f70984674f82678034b3c
