Fix: Column honours fill_height: true (iOS)#13
Closed
C-Sinclair wants to merge 1 commit into
Closed
Conversation
The .column case in MobNodeView only set maxWidth on its frame, so a Column with fill_height: true collapsed to the natural height of its children. This broke the canonical 'header / scroll / footer' layout — the footer sat directly under the last child instead of the parent's bottom edge. Pass maxHeight: .infinity when node.fillHeight is true (mirroring Box) and switch the frame alignment to .topLeading so children anchor at the top when the column flexes. Default behaviour (fill_height: false) is preserved — maxHeight stays nil and the VStack still hugs its content vertically.
Owner
|
Thanks @C-Sinclair — landed as 27c9442 in mob 0.6.15 with your authorship preserved. Six-line Swift fix for the Column |
GenericJam
added a commit
that referenced
this pull request
May 27, 2026
The Mix -> Igniter -> Zig migration shipped (apps build via build.zig, mob.new generates Zig templates, release scripts run as tested Elixir). The doc wasn't maintained past 2026-05-11, so several phases still read "in progress" though the work landed. Add a closed/historical header saying so, and flag the one open follow-up: the build orchestration hardcodes the mob Swift-source list (mob_dev release path now globs via mob_dev PR #13; mob_new's build*.zig.eex templates still list files by name and should be globbed). Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The
.columncase inMobNodeView(ios/MobRootView.swift) only setmaxWidthon its frame. AColumnwithfill_height: truethereforecollapsed to the natural height of its children — only
Boxwas honouringnode.fillHeight. This broke the canonical full-screen pattern:On iOS the footer sat directly beneath the last child instead of the parent's
bottom edge.
Change
ios/MobRootView.swift,.columncase:node.fillHeightis already parsed bymob_nif.m(same propBoxuses);no NIF or renderer changes required.
.leadingto.topLeadingso children anchor atthe top when the column flexes. When
maxHeightisnilthe VStack stillhugs its content vertically, so the default path is unchanged.
Backward compatibility
Pure addition. Default
fill_heightisfalse, matching today's intrinsic-height behaviour. No call sites need updating.
Out of scope
android/in this repo is JNI/Zig only. Compose-side parity(if needed) would live in the downstream host/demo app.
CLAUDE.mdnative UI changes are verified bymix mob.deploy --nativeplus a screenshot or
Mob.Testinteraction. Adding a test target isout of scope here.
Testing
<Column fill_width fill_height>containing aheader, a flex region, and a footer inside a fixed-height parent;
confirm the footer pins to the bottom.
fill_heightstill size to intrinsic height(no regression on existing screens).