[kokoskiwi]

Closes #10891

Intent

Keep an upward popover's choices visible above the iOS software keyboard when WebKit reports a visualViewport.offsetTop that disagrees with the layout viewport coordinates used for the trigger and boundary. In the reported case, the mismatch reduces the popover's max-height to zero.

Change

getMaxHeight now reads the visual viewport's top from the existing getContainerDimensions(document.body, visualViewport) calculation. That calculation already uses pageTop and the document scroll, and it has a separate WebKit pinch zoom path. Reading from body also preserves documents that scroll on body rather than html. The boundary and placement calculations remain otherwise unchanged.

The regression tests use the recorded iOS geometry (pageTop 466, offsetTop 310, document scroll 466, visual viewport height 404, trigger top 214). They exercise both the positioning calculation and the rendered useOverlayPosition hook. A second calculation case covers body-only scrolling. All three cases fail against the previous offsetTop calculation and pass with this change.

✅ Pull Request Checklist:

• Included link to corresponding React Spectrum GitHub Issue.
• Added/updated unit tests and storybook for this change (for new code or code which already has tests). Two regression tests were added. No new Storybook story was added because this changes sizing of an existing popover state; the existing Popover stories cover the component.
• Filled out test instructions.
• Updated documentation (if it already exists for this component). The public API and documented behavior do not change; this fixes the viewport measurement used to implement them.
• Looked at the Combobox Accessibility Practices for popup availability and interaction. ARIA semantics and keyboard behavior are unchanged.
• I understand every change in this PR and can explain why it's there.
• If AI-assisted, I followed the AI contribution guidance and pointed my assistant at AGENTS.md. This PR was prepared with Codex. A second agent reviewed the exact diff; human contributor review remains pending.

📝 Test Instructions:

• Run yarn test packages/react-aria/test/overlays/calculatePosition.test.ts packages/react-aria/test/overlays/useOverlayPosition.test.tsx --runInBand.
• On iOS Safari, open a top-placed popover from an input above the software keyboard on a scrolled page. The choices should remain visible and scrollable when visualViewport.offsetTop is positive but pageTop - document scroll is zero.
• Check a body-scrolling document and pinch zoom, where the reused viewport calculation should retain the existing behavior.

Automated verification

• yarn lint — passed (format, types, oxlint, package lint and constraints).
• yarn test --maxWorkers=4 --silent — 384 suites passed, 8,176 tests passed, 16 skipped, 262 snapshots passed. Jest reported a worker teardown warning after completion.
• yarn test:ssr --silent — 60 suites and 74 tests passed.
• Chromium and WebKit browser suite (yarn vitest run --config=vitest.browser.config.ts --project chromium-desktop --project webkit-desktop --maxWorkers=1) — 37 files and 297 tests passed, 33 skipped.
• The first yarn test:browser run failed with four TokenField timeouts, one WebKit ComboBox opening failure, and a Firefox session connection error. The failed TokenField files and WebKit ComboBox file passed when isolated; the complete Chromium and WebKit rerun above passed. Firefox still cannot connect even for a single overlay test, and a standalone Playwright Firefox launch hangs on this workstation. Firefox browser verification remains open.

The original keyboard failure was observed on an iPhone 17 Simulator running iOS 26.5. The new upstream source has a deterministic hook regression test; it has not yet been retested on the Simulator.

🧢 Your Project:

Independent application using React Aria.

[yihuiliao]

Before we review, please sign the CLA. You'll need to close and reopen the PR to rerun the check.

[snowystinger]

Need more info for reproduction #10891 (comment) so we can verify the changes.

[kokoskiwi]

I added a reduced runnable reproduction, StackBlitz import link, exact interaction steps, and the recorded iOS viewport measurements in the issue reply. The standalone page is verified to build and open in desktop Chrome; its exact iOS Safari failure state still needs confirmation.