GeezerVison

PR Checklist

• The PR title follows our guidelines: https://github.com/NativeScript/NativeScript/blob/master/tools/notes/CONTRIBUTING.md#commit-messages.
• There is an issue for the bug/feature this PR is for. To avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it.
• You have signed the CLA.
• All existing tests are passing: https://github.com/NativeScript/NativeScript/blob/master/tools/notes/DevelopmentWorkflow.md#running-unit-tests-application.
• Tests for the changes are included - https://github.com/NativeScript/NativeScript/blob/master/tools/notes/WritingUnitTests.md.

What is the current behavior?

When a page's controller view does not start at (0,0) in its superview, safe-area layout breaks on iOS. The common trigger is page.ios.edgesForExtendedLayout = UIRectEdge.Bottom with a visible navigation bar: UIKit places the controller view below the bar (y ≈ 152pt with a large title).

Two places mix the controller view's frame (superview coordinates) with values in the view's own coordinates:

1. Page.onLayout gets the native frame from View.layout() and lays out its content to bottom - insets.bottom / right - insets.right. The content ends up taller than the page by the frame offset.
2. IOSHelper.getAvailableSpaceFromParent returns fullscreen = viewControllerView.frame. expandBeyondSafeArea compares it with safeAreaLayoutGuide.layoutFrame and the in-window position, which are both relative to the controller view, so the bottom check (inWindow.bottom >= safeArea.bottom + fullscreen.top) never passes.

What you see:

• A view with iosOverflowSafeArea = true at the bottom of the page stops at the safe-area bottom instead of reaching the screen edge (under the home indicator).
• A native UIToolbar at the bottom shows a gap below it. UIKit only extends a bar's background into the bottom safe area when the bar touches its superview's safe-area bottom, and the page content is the wrong size and position for that.
• A page with edgesForExtendedLayout = Bottom inside a TabView gets its content pushed down by the offset, so the bottom rows end up under the tab bar.

What is the new behavior?

• Page.onLayout subtracts the origin: childRight = right - left - insets.right, childBottom = bottom - top - insets.bottom.
• getAvailableSpaceFromParent uses viewControllerView.bounds, so fullscreen, safeArea and inWindow share one coordinate space.

When the frame origin is (0,0), which is the default edgesForExtendedLayout = All case, both changes do nothing.

Tests

• New apps/automated test SAFEAREALAYOUT.test_overflow_reaches_bottom_when_page_view_is_offset: a page with a visible ActionBar and edgesForExtendedLayout = Bottom, holding a GridLayout with rows *, 44 and an iosOverflowSafeArea Label in the bottom row. It checks that the page view is offset, then asserts that the page, grid and label all reach the screen bottom. On the iOS 26.3 simulator (iPhone 17 Pro) it fails without this change (GridLayout.bottom - actual:2970; expected: 2622) and passes with it.
• Full apps/automated iOS suite on the same simulator: 1828 OK, 0 failed.
• Manually tested in a separate repro app: a pushed page with a large-title navigation bar and a child view controller, a fullscreen modal, a TabView, and a plain page with default edges. Each was run with an overflow label and with a native UIToolbar at the bottom. Layouts with default edges are unchanged.

Follow-ups (not in this PR)

• expandBeyondSafeArea still adds fullscreenPosition.left / fullscreenPosition.top in the right/bottom checks. Both are now always 0 on the controller-view and scroll-view paths, so the terms could be dropped.
• IOSHelper.layoutView lays out the owner with controller.view.frame when the controller has child view controllers. This has no effect today because View.layout() reads the native frame again, but bounds would be consistent with this change.
• A page with edgesForExtendedLayout = Bottom inside a TabView now lays out correctly at the bottom, but still shows an empty band of roughly 60pt under the navigation bar. It comes from the page reporting a top safe-area inset, set by the additionalSafeAreaInsets logic in UILayoutViewController.viewDidLayoutSubviews. This was already the case before this change and needs separate investigation.
• Not tested yet: iPad/landscape (left/right insets), sheet-style modals.