A row holding a sized-by-content block, a gap and a fixed button, meant to read as one cluster:
Row(
horizontalArrangement = Arrangement.Center,
modifier = Modifier.fillMaxWidth().padding(horizontal = 16.dp),
) {
BoxWithConstraints(Modifier.weight(1f, fill = false)) {
// caps each item at a maximum width, so with few items it draws narrower than maxWidth
TabCapsule(availableWidth = maxWidth, tabs = tabs)
}
Spacer(Modifier.size(12.dp))
Box(Modifier.size(56.dp)) { SearchButton() }
}
The measure pass is what matters. A Row measures its unweighted children first — here the 12dp
spacer and the 56dp button — then divides what is left into slots by weight. The weighted child is
measured against its slot with minWidth = slotWidth when fill is true (its default) and
minWidth = 0 when it is false. So fill is not "may this child stretch its content"; it is whether
the child is forced to report the slot as its own size. Filled, the children sum to exactly the
row's width, the arrangement has nothing left to place, and Arrangement.Center is a no-op: the
button sits at the edge with a hole beside it. Released, the capsule reports its content width and
the leftover becomes free space the arrangement splits — half before the cluster, half after.
Traps
The child that is wrong looks right; the sibling is the tell. The weighted child renders its content correctly at its own width — it just occupies more slot than it drew. Nothing about it is inspectable in isolation: its content is the size it asked for, its padding is what you wrote. What is visibly wrong is the neighbour, standing at the far edge of a row whose contents are nowhere near it. Read a suspicious gap as a claim made by the widget on the other side of it.
One edit is not the fix. fill = false only releases the space; the arrangement decides where it
goes. Under the default Arrangement.Start the freed width collects after the last child, which
is exactly right when a trailing label should sit next to its text and useless when the group is
meant to be centred. The two lines change together — and a release with no arrangement line above it
is relying on Start, which is why step 2 below prints them as a pair.
A filled weighted child also disables SpaceBetween and SpaceAround. Same arithmetic: the
children sum to the row's width, so there is no free space to distribute and the two ends sit at the
extremes whatever the content is. A row that pairs SpaceBetween with a weighted group is describing
an intent that only takes effect once that group stops filling.
It is a no-op at the size you designed and a bug at the size you never opened. The released width
is slot − content, which is zero whenever the content genuinely fills its budget: a full set of
tabs, a long title, a long device label all look identical under either setting. It appears only in
the narrow-content configuration — a flag off so two entries are gone, a one-word value. Resizing
the window will not reproduce it; changing the content will.
Dropping the weight is a different layout, not a simpler one. "It should just wrap, so remove the
weight" moves the child into the unweighted pass, where children are measured in declaration order
against whatever earlier ones left. A long text declared before an optional trailing badge then takes
the full width and the badge is measured against nothing — the overflow the weight was preventing.
Weighted-and-released keeps the child last in line, able to claim only what the fixed siblings left,
while still shrinking below that. The two differ exactly when the content is long, which is the
opposite end from where fill shows up.
A weighted child cannot push an unweighted sibling off the end. If something is falling off,
this modifier is not the cure: either both children carry a weight, or the row is being measured
against an unbounded width — inside a horizontal scroll, or a parent that wraps its content — where
weights have no remainder to divide. Establish which of the two before reaching for fill.
The budget and the size are two different numbers, and a self-capping child needs both. Under
fill = false a BoxWithConstraints still reports the full slot as maxWidth; only the minimum
dropped. That is what lets a child compute "each item gets maxWidth / count, capped" and then hand
the unspent remainder back. Sizing that calculation off the box's own width instead would feed the
cap its own output.
Content that fills its own maximum cancels the release. The child is now free to be narrow, not
obliged to be: anything inside it calling fillMaxWidth(), or a Row with Modifier.fillMaxWidth()
one level down, expands straight back to the slot and the row looks exactly as it did before the
edit. The release is only meaningful above content that wraps or caps itself — check the child's own
modifier chain before concluding the setting did not work.
Released width goes to the arrangement, not to the other weighted child. Slots are computed from
the remainder before any weighted child is measured, so a row with two weighted children does not
hand one of them what the other declined; the unclaimed width stays free space. Anyone reasoning from
CSS flex intuition expects the sibling to grow into it, and it does not. The vertical case is the
same modifier with the same rule — a released weighted Column child stops pinning the block below
it to the bottom of the screen.
Several sites in one release window means the default is the problem, not the screen. Step 3 prints every commit that introduced the modifier anywhere. Read the dates and the paths together: hits scattered over months are ordinary, several inside one window across unrelated screens mean the layouts being written now all want a released slot — and so will the next one.
Verifying it
# 1. Weighted children against released ones. The first is a large number in any Compose codebase,
# the second a short list — read every hit in it and name the sibling it is making room for.
grep -rn --include="*.kt" -E "\.weight\(" . | grep -v "/build/" | wc -l
grep -rn --include="*.kt" "weight(1f, fill = false)" . | grep -v "/build/"
# 2. Each release next to the arrangement of the row it sits in. A hit preceded by an
# `Arrangement.Center` line is a centred cluster; a hit that prints alone is relying on Start —
# correct for a trailing label, wrong for anything meant to be centred. Keep the window wide: a
# row's arrangement sits above ALL its children, which can be thirty lines up, and at -B10 a
# correctly centred cluster prints alone and reads as a defect.
grep -rn --include="*.kt" -B30 "weight(1f, fill = false)" . | grep -v "/build/" \
| grep -E "horizontalArrangement|verticalArrangement|weight\(1f, fill = false\)"
# 3. When each site arrived. Several inside one release window, in unrelated files, is the signal.
git log -S'fill = false' --format='%h %ad %s' --date=short -- '*.kt'
Then shrink the content, not the window: turn off whatever gates an item so the group has two entries instead of four, or feed the field a one-word value. Filled, the neighbour stays welded to the edge and the gap beside it grows as the content shrinks — that inverse relationship is the confirmation, since a correctly centred cluster moves its neighbour inward instead. Check both ends: at full content the two settings are indistinguishable, so a screenshot taken there proves nothing either way. Then repeat with the longest value you can produce, which is where the "just drop the weight" variant fails and this one does not.
Related: nav-tab-registration-drift (the item count this row's content depends on is itself
conditional, and changing it is what exposes a filled slot), responsive-gate-size-not-platform (the
other half of an adaptive row — the arrangement answers for content size, the gate for window shape).