fix(macos-helper): scroll SwiftUI forms whose rows are scroll-area children

Merged
JA
2d ago
+47-6

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: