Now mfbt/Move.h is empty except for that excellent comment about move
semantics... Should we put it somewhere else and delete the header as a
follow-up? Or just delete the header and carry on?
Differential Revision: https://phabricator.services.mozilla.com/D60297
This prevents grid container frames from being considered subgrid (even when
they have contain:layout/paint) when they are themselves a grid item of a
contain grid.
Differential Revision: https://phabricator.services.mozilla.com/D59790
The order of argument evaluation is implementation-defined, so we can't trust
whether the .Length() or the std::move() will get executed first. This is OK
right now since the constructor takes the argument by rvalue and so it can't be
emptied out before the .Length() call. However, a change to the types in the
constructor's argument list could make this still compile, but then depend on
compiler-dependent argument evaluation order to get the correct result.
Differential Revision: https://phabricator.services.mozilla.com/D59238
The information in it is always derivable from the values of mRepeatAutoStart
and mRepeatAutoEnd. Additionally, its value is used in some cases where it has
not yet been set properly (such as CalculateRepeatFillCount).
This works out currently because the default value is zero we only accept
repeat(auto-fill, ...) and repeat(auto-fit, ...) CSS values that have a single
element in the repeat. In that case, zero is the correct value for
RepeatEndDelta.
Differential Revision: https://phabricator.services.mozilla.com/D58871
This changeset is a simple find and replace of `MOZ_FALLTHROUGH` and `[[fallthrough]]`.
Unfortunately, the MOZ_FALLTHROUGH_ASSERT macro (to assert on case fallthrough in debug builds) is still necessary after switching from [[clang::fallthrough]] to [[fallthrough]] because:
* MOZ_ASSERT(false) followed by [[fallthrough]] triggers a -Wunreachable-code warning in DEBUG builds
* but MOZ_ASSERT(false) without [[fallthrough]] triggers a -Wimplicit-fallthrough warning in NDEBUG builds.
Differential Revision: https://phabricator.services.mozilla.com/D56440
Note that the GetXULPrefSize API might still do a "::BoxReflow" under the hood,
inside its call to RefreshSizeCache.
Also: we can't use GetLogicalUsedMargin() in this special case, because the
child may not have been reflowed (which is what populates the "used margin"
frame property). So instead, we pull the margin off of the reflow state.
As noted in the code-comment alongside that call, this won't work with
percent margins, but hopefully we can just avoid those in our frontend code
that uses XUL-in-grid-items.
Also, this patch makes the grid call ReflowChild() on its grid items using
a loose guess at their position, rather than at position 0,0. This helps
popup frames figure out their size during reflow and size their children
properly.
Differential Revision: https://phabricator.services.mozilla.com/D54886
I couldn't repro this with the STR in the bug, but I can repro by inspecting a
grid in print preview, where we don't properly honor the re-reflow request
because $reasons.
Differential Revision: https://phabricator.services.mozilla.com/D55264
Per the spec, if multiple track sizes are given, the pattern is repeated as
necessary to find the size of the implicit tracks:
1. The first implicit grid track after the explicit grid receives the first
specified size, and so on forwards.
2. The last implicit grid track before the explicit grid receives the last
specified size, and so on backwards.
We use a positive index of the auto track sizes for (1) and a negative index
for (2), so we can apply the correct specified implicit size.
Differential Revision: https://phabricator.services.mozilla.com/D52265
It seems better to convert this before adding a new flag (in bug
1547759) and risking replacing the wrong 0 with a flag.
Differential Revision: https://phabricator.services.mozilla.com/D40562
I'm _really_ sorry for the size of the patch. I tried to do this in two steps
but it was a lot of work and pretty ugly.
This patch makes us use cbindgen for grid-template-{rows,columns}, in order to:
* Make us preserve repeat() at computed-value time. This is per spec since
interpolation needs to know about repeat(). Except for subgrid, which did the
repeat expansion at parse-time and was a bit more annoying (plus it doesn't
really animate yet so we don't need it to comply with the spec).
* Tweaks the WPT tests for interpolation to adopt the resolution at:
https://github.com/w3c/csswg-drafts/issues/3503.
Trade-off here, as this patch stands, is that this change makes us use less
long-living memory, since we expand repeat() during layout, but at the cost of a
bit of CPU time during layout (conditional on the property applying though,
which wasn't the case before). It should be very easy to store a cached version
of the template, should this be too hot (I expect it isn't), or to change the
representation in other ways to optimize grid layout code if it's worth it.
Another trade-off: I've used SmallPointerArray to handle line-name merging,
pointing to the individual arrays in the style data, rather than actually
heap-allocating the merged lists. This would also be pretty easy to change
should we measure and see that it's not worth it.
This patch also opens the gate to potentially improving memory usage in some
other ways, by reference-counting line-name lists for example, though I don't
have data that suggests it is worth it.
In general, this patch makes much easier to tweak the internal representation of
the grid style data structures. Overall, I think it's a win, the amount of magic
going on in that mako code was a bit huge; it took a bit to wrap my head around
it.
This patch comments out the style struct size assertions. They will be
uncommented in a follow-up patch which contains some improvements for this type,
which are worth getting reviewed separately.
Also, this patch doesn't remove as much code as I would've hoped for because of
I tried not to change most of the dom/grid code for inspector, but I think a
fair bit of the nsGridContainerFrame.cpp code that collects information for it
can be simplified / de-copy-pasted to some extent. But that was a pre-existing
problem and this patch is already quite massive.
Differential Revision: https://phabricator.services.mozilla.com/D36598
Our algorithm for dividing a page up into separate font inflation flow roots
seems mostly based on the idea that a new Block Formatting Context (BFC) should
go hand in hand with a font inflation flow root.
Flex containers so far didn't follow that rule, since they technically create a
new *Flex* Formatting Context (FFC) and possibly also because nobody thought
about font inflation when implementing nsFlexContainerFrame.
This leads to all flex containers being counted against the next higher-level
flow root, meaning that a lot of small flex containers can get inflated if their
sum total of text *collectively* exceeds the font inflation threshold.
This alone is likely undesired most of the time, but is then also aggravated by
the fact that our flexbox behaviour under font inflation is somewhat buggy (bug
1142461).
As apart from the different layout rules inside the container, a FFC behaves
very much like a BFC in that it establishes a new formatting context, flex
containers should therefore correspondingly become font inflation flow roots,
too, and therefore be considered individually for font inflation.
As far as I can tell, with this change we'll also match Blink's behaviour in
that regard.
For completeness's sake, we'll make grid containers follow the same principles,
even though hopefully grids on non mobile-friendly pages should hopefully be
somewhat rarer than flexboxes.
Differential Revision: https://phabricator.services.mozilla.com/D32622
We clamp earlier (parse time rather than computed value time), but that's the
only behavior change, which I think doesn't really matter.
Differential Revision: https://phabricator.services.mozilla.com/D35198
We clamp earlier (parse time rather than computed value time), but that's the
only behavior change, which I think doesn't really matter.
Differential Revision: https://phabricator.services.mozilla.com/D35198
Both for symmetry with other string APIs, and also to prevent footguns (since I
debugged for a while a typo where I wrote nsGkAtoms::empty rather than
nsGkAtoms::_empty).
We could use null here, but that will not be possible in the future when I use
the rust representation of more grid data structures (at least without
increasing memory usage).
So I think I'll keep using ::_empty as a signaling value for "no grid
identifier".
Differential Revision: https://phabricator.services.mozilla.com/D35120
The style system already atomizes all CustomIdent values, which means that we're
just wasting memory and CPU by doing string copies all over the place.
This patch fixes it. This also simplifies further changes to use as much of the
rust data structures as possible.
I had to switch from nsTHashtable to mozilla::HashTable because the former
doesn't handle well non-default-constructible structs (like NamedLine, which
now has a StyleAtom, which is not default-constructible).
Differential Revision: https://phabricator.services.mozilla.com/D35119
Right now we do a lot of useless string copying. In order to avoid transcoding
to utf-16 during layout, make sure to use nsCString at a few related places.
I may revisit this since we're storing other line names as atoms in some places.
So it may be better to just use atoms everywhere.
But that'd be a different patch either way.
Depends on D35116
Differential Revision: https://phabricator.services.mozilla.com/D35117
We previously (in bug 1491235) adjusted some utility code to make
layout-contained frames behave as if they have no baseline.
But that's not sufficient. To make frames fully report lack-of-a-baseline,
we now do the following for layout-contained frames, as of this patch:
(a) We now leave the ReflowOutput outparam's BlockStartAscent member at its
default value (which is what we do for frames without a baseline like
e.g. nsCheckboxRadioFrame and nsHTMLCanvasFrame). And if the parent cares
about the baseline, it'll then ask directly, using a baseline getter.
(b) We now return 'false' in more implementations of bool-returning
baseline-getter-methods (where 'false' indicates 'no baseline').
(c) We now return the margin-box-bottom edge, in the nscoord-returning
'GetLogicalBaseline()' getter method. (We typically do this by deferring
to the inherited method, which ultimately comes from nsFrame's
implementation). It's appropriate to use the margin-box-bottom edge when
there's no baseline, per the definition of 'vertical-align: baseline',
here: https://drafts.csswg.org/css2/visudet.html#propdef-vertical-align
Depends on D32182
Differential Revision: https://phabricator.services.mozilla.com/D32183
We previously (in bug 1491235) adjusted some utility code to make
layout-contained frames behave as if they have no baseline.
But that's not sufficient. To make frames fully report lack-of-a-baseline,
we now do the following for layout-contained frames, as of this patch:
(a) We now leave the ReflowOutput outparam's BlockStartAscent member at its
default value (which is what we do for frames without a baseline like
e.g. nsCheckboxRadioFrame and nsHTMLCanvasFrame). And if the parent cares
about the baseline, it'll then ask directly, using a baseline getter.
(b) We now return 'false' in more implementations of bool-returning
baseline-getter-methods (where 'false' indicates 'no baseline').
(c) We now return the margin-box-bottom edge, in the nscoord-returning
'GetLogicalBaseline()' getter method. (We typically do this by deferring
to the inherited method, which ultimately comes from nsFrame's
implementation). It's appropriate to use the margin-box-bottom edge when
there's no baseline, per the definition of 'vertical-align: baseline',
here: https://drafts.csswg.org/css2/visudet.html#propdef-vertical-align
Depends on D32182
Differential Revision: https://phabricator.services.mozilla.com/D32183
