[janicduplessis]

Summary

With AGENT_DEVICE_MACOS_APP_BACKEND=native, every scroll in a SwiftUI Form (such as a Settings window) failed with no scroll area with a settable scroll bar under the window center.

The helper sized the content from the largest child of the AXScrollArea, but a Form lists each heading and row group as a direct child of the area. No child was taller than the area, so the overflow came out negative and the area was skipped. The overflow now comes from the span all non-scroll-bar children cover. One document view gives the same value as before.

Known limits:

• A child far outside the content on the scroll axis, such as a detached header overlay, widens the span, so each step travels less. Filtering by position would also drop rows scrolled out of view. A test pins the value.
• Lazily realized children (SwiftUI List and LazyVStack) only expose on-screen rows, so overflow can be underestimated. That is pre-existing, and not made worse by this PR.

2 files. Related: #3213.

Validation

Head 0878411bd, base c8b944ca0.

• pnpm check:affected --base upstream/main --head 0878411bd --run: passed, exactCommit: true; selected checks are GitHub-authoritative (Apple / Smoke Tests).
• swift test in apple/macos-helper: 20 passed.
• Live at 50acc2d96 (head adds only a test and comment trims), macOS 27, Stim Desktop's Settings window, native backend: base refuses scroll down, bottom, --pixels and --until; head passes all, and --until reaches an off-screen switch that a press then toggles.

Top of the form, then after scroll --until and the press:

[Copilot]

🔵 Needs a closer look

Smoke tests, coverage, and repository guards are still running, so validation remains incomplete.

No open issues 🎉

What changed in this PR

Fixes scrolling in SwiftUI forms under the opt-in native macOS backend by measuring content across all scroll-area children rather than selecting the largest child.

Changes:

• Calculate overflow from the combined span of non-scroll-bar children.
• Add regression tests for multiple rows, distant children, and empty frames.

File	Description
apple/​macos-helper/​Tests/​AgentDeviceMacOSHelperTests/​BackgroundInteractionTests.swift	Tests content-span calculations and boundary cases.
apple/​macos-helper/​Sources/​AgentDeviceMacOSHelper/​BackgroundInteraction.swift	Uses combined child bounds to calculate scroll overflow.

_{Review effort: Balanced}

[thymikee]

This PR is ready for review at 0878411. I found no problems in the code, and CI is green: 14 checks reported and none failed. The diff only touches the macOS helper scroll-bar route, which the Apple and Smoke Tests jobs exercise. There are no conflicts.

Not blocking, and you can take or leave these: the test testScrollOverflowCountsAChildFarOutsideTheContent at https://github.com/callstack/agent-device/blob/0878411/apple/macos-helper/Tests/AgentDeviceMacOSHelperTests/BackgroundInteractionTests.swift#L93 asserts 5680, the inflated overflow from a detached header, so it pins a known limit as expected behavior. You could rename it to say so, or drop it once outlier filtering lands. The doc comment at https://github.com/callstack/agent-device/blob/0878411/apple/macos-helper/Sources/AgentDeviceMacOSHelper/BackgroundInteraction.swift#L262 could add one clause: lazily realized rows make the span a lower bound.

On evidence, the live Settings Form run was at 50acc2d, not at this commit. Since then the source only changed a doc comment, so that run still covers the scroll change. I did not run swift test or inspect a live AX tree. The lazy-row limit for SwiftUI List and LazyVStack was already there and is stated in the PR body. I did not test it.