This patch is generated by running the following script under layout/,
and then manually delete the FIXME comment in LayoutConstants.h
#!/bin/bash
function rename() {
find .\
-type f\
! -path "./obj*"\
! -path "./.git"\
! -path "./.hg"\
\( -name "*.cpp" -or\
-name "*.h" \)\
-exec sed -i -e "s/$1/$2/g" "{}" \;
}
rename NS_INTRINSIC_WIDTH_UNKNOWN NS_INTRINSIC_ISIZE_UNKNOWN
Differential Revision: https://phabricator.services.mozilla.com/D29746
--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 moves some `enum` in `nsIPresShell` which are in public scope into
`mozilla` namespace and change them as `enum class`es.
Unfortunately, only "where to scroll" enum is just defines constants of
percentages of scroll destination. Therefore, this patch makes only them
as `static const`.
Differential Revision: https://phabricator.services.mozilla.com/D28606
--HG--
extra : moz-landing-system : lando
Additionally, this patch makes `nsFrame.h` stop including `nsIPresShell.h`
and makes each users include `mozilla/PresShell.h` instead. So, this improves
rebuild performance of `nsIPresShell.h` (and `mozilla/PresShell.h` in the
future).
Note that due to `nsIFrame::PresShell()`, `mozilla::` prefix is necessary for
`PresShell` in a lot of classes which are derived from `nsIFrame` even in
`.cpp` files.
Differential Revision: https://phabricator.services.mozilla.com/D27476
--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
Except retrieving from weak reference, `nsIFrame` should treat
`mozilla::PresShell` directly rather than via `nsIPresShell`.
Differential Revision: https://phabricator.services.mozilla.com/D26388
--HG--
extra : moz-landing-system : lando
`nsPresContext` should use `mozilla::PresShell` directly instead of
`nsIPresShell`. This patch makes it.
Unfortunately, `nsPresContext` and `nsIFrame` have `PresShell()`. Therefore,
we cannot use `PresShell*` in its methods so that this patch uses `mozilla::`
namespace prefix.
It might be better to rename them as `PresShellPtr()` in another bug.
Differential Revision: https://phabricator.services.mozilla.com/D25721
--HG--
extra : moz-landing-system : lando
Converted the #define variable NS_STYLE_FLEX_DIRECTION to an enum class in nsStyleConsts.h and made changes in other files that access it
Differential Revision: https://phabricator.services.mozilla.com/D20291
--HG--
extra : moz-landing-system : lando
This is more consistent with what the Rust bits of the style system do, and
removes a pointer from ComputedStyle which is always nice.
This also aligns the Rust bits with the C++ bits re. not treating xul pseudos as
anonymous boxes. See the comment in nsTreeStyleCache.cpp regarding those.
Can't wait for XUL trees to die.
Depends on D19001
Differential Revision: https://phabricator.services.mozilla.com/D19002
--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
For elements that have box-sizing:border-box specified, the aspect ratio
calculation code subtracts out border & padding from any specified property
values.
So, when we create a fake "override" specified property value for a flex item
whose main size has been resolved, we need to add in the border and padding to
account for the fact that they're going to be subtracted out later.
Differential Revision: https://phabricator.services.mozilla.com/D17712
--HG--
rename : layout/reftests/w3c-css/submitted/flexbox/flexbox-intrinsic-ratio-001-ref.html => layout/reftests/w3c-css/submitted/flexbox/flexbox-intrinsic-ratio-007-ref.html
rename : layout/reftests/w3c-css/submitted/flexbox/flexbox-intrinsic-ratio-001.html => layout/reftests/w3c-css/submitted/flexbox/flexbox-intrinsic-ratio-007.html
rename : layout/reftests/w3c-css/submitted/flexbox/flexbox-intrinsic-ratio-001v.html => layout/reftests/w3c-css/submitted/flexbox/flexbox-intrinsic-ratio-007v.html
extra : moz-landing-system : lando
This patch doesn't change behavior; it's just making some custom cleanup
code unnecessary by using a better fitting container class.
Differential Revision: https://phabricator.services.mozilla.com/D11237
--HG--
extra : moz-landing-system : lando
Keywords on the sizing properties in the block axis should behave as
initial values in the flex frame. We store the keywords as enum, instead
of auto or none in nsStyleCoord, so we have to handle it explicitly.
Differential Revision: https://phabricator.services.mozilla.com/D9438
--HG--
extra : moz-landing-system : lando
This patch basically reverts the functional part of changeset 52bd865d757c.
I'd optimistically hoped we could skip this early-freeze in order to compute &
report a bit more "potential flexing" information via devtools. Bbut it turns
out that breaks assertions & produces bogus information for flex items whose
base size vs. min/max-clamped "hypothetical" sizes are very
different. (Specifically: it produces nonsense for flex items whose base sizes,
if unclamped, would reverse the directionality of flexing.)
Differential Revision: https://phabricator.services.mozilla.com/D9304
--HG--
extra : moz-landing-system : lando
This patch also updates the expectations in the mochitest test_flex_items.html.
Before this commit, the test (incorrectly) expected the mainBaseSize API to
return some items' *final sizes*, because that's what our implementation did
return, up until now. As of this patch, that API will now return the item's
actual flex base size, which means the text expectations need to change.
I'm also adding a new flex item to the test, to exercise a formerly-untested
scenario. And to accommodate this new item, I'm also doubling the width of
the flex container to be sure there's plenty of space.
Differential Revision: https://phabricator.services.mozilla.com/D8476
--HG--
extra : moz-landing-system : lando
Frozen flex items have already been clamped to their min/max sizes, so their
size-change isn't a "how much we want to flex" measurement, and it's not useful
for determining whether the rest of the line is shrinking.
This patch is just adding a `if (!item->IsFrozen())` check around some code,
and reindenting that code, and adjusting a few comments.
This change is necessary to avoid failing the "GrowthState" assertions,
because (for example) a flex item that's clamped to a small max-width
could fool us into thinking we're in a "shrinking" state (since its final
size is smaller than its base size), even though really we're
in a "growth" state and the item was simply clamped. We avoid this
problem by skipping (potentially-clamped) frozen items when determining
the line's GrowthState.
Depends on D8922
Differential Revision: https://phabricator.services.mozilla.com/D9018
--HG--
extra : moz-landing-system : lando
We'd like to be able to record the "desired" (pre-clamped) delta size from
tentatively flexing for these items. That size would be computed during a loop
of the flex layout algorithm -- but we can't do that if we freeze them before
we start flexing. So let's bypass this early freeze so they get a chance to
compute this tentative size, even though they can never have it.
Differential Revision: https://phabricator.services.mozilla.com/D8922
--HG--
extra : moz-landing-system : lando
The CSSWG has recently resolved that layout containment
suppress baseline alignment, while size containment does not:
https://github.com/w3c/csswg-drafts/issues/2995
Spec text (https://drafts.csswg.org/css-contain/#containment-layout):
"7. For the purpose of the vertical-align property,
or any other property whose effects need to relate
the position of the containing element's baseline
to something other than its descendants,
the containing element is treated as having no baseline."
And a note in (https://drafts.csswg.org/css-contain/#containment-size):
"Note: size containment does not suppress baseline alignment.
See layout containment for that."
This patch does this change just switching IsContainSize()
by IsLayoutSize() in several places related to baseline alignment
in the source code.
With the patch several WPT tests start to pass. Apart from that,
some of the tests under vendor-imports are updated to follow
the new behavior.
--HG--
extra : amend_source : 05dc9a320afeb1d58981e2bd8bc47b435999f2f9