Also, simplify some callers of `GetScrollTargetFrame()` to drop
`nsIScrollableFrame*` and unnecessary `do_QueryFrame`. We'll continue removing
more `nsIScrollableFrame*` in later parts.
Differential Revision: https://phabricator.services.mozilla.com/D211490
The two macros are used in `GetPrefISize()` and `GetMinISize()` implementations.
After removing them, we could further simplify some implementations because we
don't need a `result` variable in many cases.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D206316
LogicalAxis is one of the Logical* enums. Converting it from enum to
enum class increases type safety. To run with the pre-existing code,
type casting was added when needed. Comments have been edited where
needed.
Differential Revision: https://phabricator.services.mozilla.com/D206108
Values were static_casted where required. Some functions in WritingModes.h were
rewritten such that bitwise operations aren't being used. Added static_casts to
avoid (debug) build errors from debugging printfs in layout/tables/nsCellMap.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D205510
https://drafts.csswg.org/css-align-3/#baseline-terms
The baseline sharing group is not equal to the baseline specified for
the item. It has to be calculated separately. The baseline sharing
group determines on which side of the block the item is aligned, but the
specified baseline is still used to determine the baseline of the item.
Depends on D200767
Differential Revision: https://phabricator.services.mozilla.com/D200768
https://drafts.csswg.org/css-align-3/#baseline-terms
The baseline sharing group is not equal to the baseline specified for
the item. It has to be calculated separately. The baseline sharing
group determines on which side of the block the item is aligned, but the
specified baseline is still used to determine the baseline of the item.
Differential Revision: https://phabricator.services.mozilla.com/D200768
https://drafts.csswg.org/css-align-3/#baseline-terms
The baseline sharing group is not equal to the baseline specified for
the item. It has to be calculated separately. The baseline sharing
group determines on which side of the block the item is aligned, but the
specified baseline is still used to determine the baseline of the item.
Differential Revision: https://phabricator.services.mozilla.com/D200768
This avoids using raw integer values which might cause bugs.
Also removed a clang-format: off block for better formatting.
Differential Revision: https://phabricator.services.mozilla.com/D200767
This avoids using raw integer values which might cause bugs.
Also removed a clang-format: off block for better formatting.
Differential Revision: https://phabricator.services.mozilla.com/D200767
Before this patch, when we baseline-aligned items in a grid, we were careful to
include items from subgrids in that alignment geometry. However, we ended up
dropping the baseline alignment metrics for those subgrid items on the floor,
per the code-comment and TruncateLength call here:
https://searchfox.org/mozilla-central/rev/b580e3f77470b2337bc8ae032b58a85c11e66aba/layout/generic/nsGridContainerFrame.cpp#3744-3747
This patch makes us propagate subgrid items' baseline-alignment metrics to
their actual GridItemInfo structs (which canonically live in the Subgrid()
frame-property on their direct subgrid parent).
Now that those baseline-alignment metrics are having an effect, we can also see
that the (previously-ignored) metrics are wrong in some cases -- they don't
properly account for various forms of padding on subgrid containers of
baseline-aligned grid items. That's tracked in bug 1871719, and that's the
reason this patch has several WPT subtests, which were previously passing.
(They were passing just by chance, since our previous trivial-fallback behavior
happened to place some items at the correct start/end-aligned location, and our
new baseline-aligned location happens to be incorrect due to bug 1871719.)
Since this patch is regressing those cases: out of an abundance of caution, I'm
putting the new behavior behind an about:config preference
"layout.css.grid-subgrid-baselines.enabled" (defaulting to true in Nightly,
false in other builds), so that this patch will have no behavioral effect for
users of release builds. We can remove the about:config pref once bug 1871719
is fixed.
Differential Revision: https://phabricator.services.mozilla.com/D197233
This patch doesn't change behavior; it's just a rename.
We have an "entry-point" function CollectSubgridItemsForAxis that the outer
grid calls, and most of its work is done by a recursive helper function.
Before this patch, the recursive helper function has nearly the same name but
with the word "Items" removed, which doesn't make any sense, since it's still
collecting items from subgrids.
Let's just rename the recursive helper to match its entry-point, with a
"Helper" suffix, and document that it's a recursive helper. This makes the
function name a little longer, but not too much longer.
(I'm bothering to do this because the next patch in this series will add a
similar pair of functions, and I want the new functions to use the same naming
scheme as these existing functions.)
Differential Revision: https://phabricator.services.mozilla.com/D197232
This patch doesn't change behavior.
Before this patch, we're appending to the array that we're iterating over,
which is risky, though it happens to be safe right now since we don't use
any of the newly-invalid-data after the array is mutated.
This patch just uses a less risky approach (appending to a temporary array)
to avoid this fragility.
Differential Revision: https://phabricator.services.mozilla.com/D197217
When the subgrid gap forces a track to have a negative size, the old code was
clamping the track-size (`mBase`) to 0, but it was still placing that track at
`mPosition` that reflected its theoretical negative-size (shifting it
startwards). This patch removes that startwards shift.
Note on the tests: the existing grid-gap-011.html doesn't test the code change
around `lastTrack`. That is, we still pass the test without the position fix to
`lastTrack`. Hence I added grid-gap-012.html, which is adapted from
grid-gap-011.html, but with the subgrid gap changed to 250px (larger than the 2x
track size to test the position of the last track). Both Chrome and Safari
already pass the test.
Differential Revision: https://phabricator.services.mozilla.com/D197084
This is a slight change to our "clamping over-large grid" procedure (
https://www.w3.org/TR/css-grid-2/#overlarge-grids ) to more closely match the
spec requirements.
Per spec, we use this same procedure for two different things:
(a) to clamp the placement of grid items that are using extremely large grid line indices -- beyond 10,000.
(b) to clamp grid lines that are simply outside the bounds of their subgrid.
(Of course (b) is much more mundane, but the spec says to "[use] the same
procedure" at https://www.w3.org/TR/css-grid-2/#subgrid-implicit )
Before this patch, we were preemmptively clamping each of a grid item's
specified grid-lines at the moment that we resolve the individual line. This
approach doesn't quite match the #subgrid-implicit spec text linked above,
which says to create implicit grid lines (i.e. lines *beyond the clamp-limits*)
as-needed when placing the grid item; and only clamp once we've determined the
grid area (i.e. once we've resolved all of the grid lines).
The distinction is subtle, but it makes a difference for cases like the bottom
half of https://bug1800566.bmoattachments.org/attachment.cgi?id=9369740 , where
we have to search backwards from the end line in order to find a named line to
use as the item's start-line. The outcome ends up wrong if we clamp the end
line before we do that search (as we were doing before this patch) vs. if we do
the search first and then clamp the range as a whole afterwards.
See comments in the patch for more details.
Differential Revision: https://phabricator.services.mozilla.com/D197044
This patch only changes behavior in cases where the following conditions hold:
(a) We're asking an item for its baseline, and the item has a writing-mode
that uses a central baseline (e.g. vertical-rl).
(b) We're asking for a baseline **in that item's inline axis**, i.e. a
measurement in the y-axis.
In this situation, the item really only wants to use central baselines for its
own block-axis baselines, not for its inline-axis baselines. So let's not
bother trying to generate central baselines in its inline axis.
This is documented to some extent in
https://www.w3.org/TR/css-writing-modes-4/#text-baselines, which describes
central baselines as being between the 'over' and 'under' edges (aka
'line-over' and 'line-under'), i.e. a measurement in the element's own block
axis.
This makes us pass WPT subgrid-stretch.html, because it happens to depend on
the baseline alignment of horizontal-writing-mode grids that have
vertical-writing-mode subgrids.
Differential Revision: https://phabricator.services.mozilla.com/D196932
This patch does two things:
1. Extends ShouldInhibitSubgridDueToIFC to return true for out-of-flow frames,
per spec (which makes us pass the WPT independent-formatting-context.html).
Spec reference: https://drafts.csswg.org/css-grid-2/#subgrid-listing
"...if the grid container [the one that's styled to be a subgrid] is
otherwise forced to establish an independent formatting context (for
example, due to layout containment or absolute positioning), the used value
is the initial value, 'none', and the grid container is not a subgrid."
2. Removes some newly-dead code from ComputeSelfSubgridMasonryBits that
provided some special handling for out-of-flow subgrids (which are now
impossible to create, as of this change); and also remove
WillHaveAtLeastOneTrackInAxis() whose last caller I'm removing here.
3. Renames a variable 'gridParent' to 'parentGrid' to match the spec
terminology at https://drafts.csswg.org/css-grid-2/#parent-grid
Differential Revision: https://phabricator.services.mozilla.com/D193731
This patch doesn't change behavior.
The code that follows the new early-return is all in the service of making
changes to the return value `bits`; and all of the modifications are guarded
directly or indirectly by checks for `!inhibitSubgrid`. So we might as well
just morph this `inhibitSubgrid` variable into an early-return and skip all of
that code entirely when it evaluates to true.
Differential Revision: https://phabricator.services.mozilla.com/D196900
This ComputeSelfSubgridMasonryBits() function has some logic to determine
whether a grid is using subgrid layout (i.e. participating in a parent grid)
and also whether it's using masonry layout at all.
There's one early-return for a case where we can't be a subgrid, which
inadvertently also disregards the masonry state that we've set. It looks like
this was an oversight, since in fact we can still use masonry regardless of
whether we're allowed to be a subgrid.
Differential Revision: https://phabricator.services.mozilla.com/D196891
Rename to make them clearer that they stores child's axes in grid container's
writing-mode. Without the "InWM" suffix, it's a bit confusing why not just use
`eLogicalAxisInline`.
Differential Revision: https://phabricator.services.mozilla.com/D196703
When a grid item is set to align itself to the baseline (first or last)
then it should participate in baseline alignment if the item's size is
not dependent on the size of the track and vice versa.
Also added a test to check for last baseline alignment in addition to
first baseline alignment on empty blocks.
Differential Revision: https://phabricator.services.mozilla.com/D157345
When a grid item is set to align itself to the baseline (first or last)
then it should participate in baseline alignment if the item's size is
not dependent on the size of the track and vice versa.
Also added a test to check for last baseline alignment in addition to
first baseline alignment on empty blocks.
Differential Revision: https://phabricator.services.mozilla.com/D157345
When a grid item is set to align itself to the baseline (first or last)
then it should participate in baseline alignment if the item's size is
not dependent on the size of the track and vice versa.
Also added a test to check for last baseline alignment in addition to
first baseline alignment on empty blocks.
Differential Revision: https://phabricator.services.mozilla.com/D157345
I forgot to use a reference when doing the refactoring. We should use a
reference to a pointer because we rely on the information from the previous
iteration, in the private function, `AddImplicitNamedAreasInternal()`.
Note: I don't have a test for this. This bug is from a real website:
https://www.oddbird.net/tools/, and it's not easy to reduce the
testcase, so we may need a QA to verify this by the real website.
Differential Revision: https://phabricator.services.mozilla.com/D195388
