Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Before, there existed 3 virtual functions that calculated baselines:
- `GetLogicalBaseline`
- `GetVerticalAlignBaseline`
- `GetNaturalBaselineBOffset`
Each of them had slightly different behaviours:
- `GetLogicalBaseline` would synthesize a baseline if there is no baseline.
Others would simply return `false`.
- `GetNaturalBaselineBOffset` requires the caller to pick which of first/last
baseline to calculate. Others pick on on their own.
- `GetNaturalBaselineBOffset`'s result can be either offset from border box
start/end edge, depending on the caller-supplied baseline. Others always
return offset from border box start edge.
Now:
- `GetNaturalBaselineBOffset` is the sole virtual function.
- `GetLogicalBaseline` exists to support its use, with 2 virtual helper functions:
- `SynthesizeFallbackBaseline` to generate a baseline for elements that
doesn't have one.
- `GetBaselineSharingGroup` to preserve the default baseline picking behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D167990
This ensures that repeated calls to Element::GetGridFragments will return
an array of idempotent Grid objects for each fragment. This is
accomplished by making the Grid object hold a WeakFrame back to its
originating frame, and updating a property on construction and
destruction.
Differential Revision: https://phabricator.services.mozilla.com/D169724
This ensures that repeated calls to Element::GetGridFragments will return
an array of idempotent Grid objects for each fragment. This is
accomplished by making the Grid object hold a WeakFrame back to its
originating frame, and updating a property on construction and
destruction.
Differential Revision: https://phabricator.services.mozilla.com/D169724
Instead of digging into the first line-iterable frame. Digging into the
first line-iterable frame is bogus, because if there are multiple flex
items we might prevent moving through them properly (see test-case).
The flex implementation is nice and fairly complete, IMO. The grid one
is not, but the resulting behavior is nicer than the behavior before
this patch, seems reasonable, and matches Chrome in my testing.
In Searchfox, the behavior is even funnier because user-select: none is
involved, but that predates the regression.
Differential Revision: https://phabricator.services.mozilla.com/D158086
Some of our GetNaturalBaselineBOffset implementations already have this; others
don't. But they all should have it, or else a caller might improperly query
their baseline and use it for layout despite the frame having 'contain:layout'.
Without this patch, the rest of this patch-stack makes us fail WPT test
contain-layout-suppress-baseline-002.html because we improperly honor the
baseline for the 'contain:layout' buttons at the top of the test.
Differential Revision: https://phabricator.services.mozilla.com/D121938
nsContainerFrame.h was only using the enum nsLayoutUtils::IntrinsicISizeType,
which this patch moves to LayoutConstants.h instead.
Depends on D91505
Differential Revision: https://phabricator.services.mozilla.com/D91506
* It's easier to maintain the type aliases of in one place, i.e.
CSSOrderAwareFrameIterator.h, and the iterator's header itself doesn't
include a lot of headers that add complex dependencies to
nsGridContainerFrame.h.
* Make "jump to definition" functionality in editors work
correctly (rather than just jumping to those declarations.)
Differential Revision: https://phabricator.services.mozilla.com/D81281
AutoFrameListPtr might be used more frequently after we add more APIs to
handle overflow container list and excess overflow container list in
bug 1641085.
The improvements in this patch includes:
* Mark AutoFrameListPtr as MOZ_RAII and final class.
* Move AutoFrameListPtr into mozilla namespace since we don't use layout
sub-namespace that much these days.
* Remove the AutoFrameListPtr type alias in nsGridContainerFrame's
header since it's not used.
Differential Revision: https://phabricator.services.mozilla.com/D77568
This provides stronger typing and removes a bunch of subtle constants matching.
Differential Revision: https://phabricator.services.mozilla.com/D61058
--HG--
extra : moz-landing-system : lando
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
For now, always pass null, except when passing it through from one
overload to another.
Differential Revision: https://phabricator.services.mozilla.com/D38389
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
