fix(ui-ios): #5200 — scrollViewSetOffset binds y, restores without animation#5449
Conversation
…imation The `scrollViewSetOffset` dispatch row already declares three args (Widget, F64, F64), but the iOS FFI and impl took a single `offset` and bound it to the first f64 (x). `setContentOffset` therefore got `(0, x)` with x almost always 0, snapping the view to the top instead of the requested y. Restoring scroll position across rebuilds (`scrollViewSetOffset(sv, 0, savedY)`) always jumped to the top. Take both coordinates through the FFI into the impl, and set the offset without animation since this is used to restore position. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThe iOS scroll view FFI function ChangesScroll Offset x/y Fix
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
Fixes #5200.
Problem
scrollViewSetOffset(sv, x, y)ignoredyand always usedx. The shared dispatch row already declares three args (Widget, F64, F64):…but the iOS FFI and impl took a single
offsetand bound it to the first f64 (x):So
setContentOffsetreceived(0, x)with x almost always0, and any caller doingscrollViewSetOffset(sv, 0, savedY)snapped to the top instead ofsavedY— scroll-position restoration broke on every rebuild.Fix
Thread both coordinates through the FFI into the impl, and set the offset without animation (this path restores position, so animating is wrong):
cargo check -p perry-ui-iosis clean (only pre-existing warnings).Note
The same single-offset signature exists in the other native UI backends (
perry-ui-macos,tvos,visionos,android,gtk4,windows) and the JS/wasm runtimes, all fed by the same 3-arg dispatch row — so they share this latent y-ignored bug. This PR is scoped to iOS per the issue; the sibling backends are worth a follow-up.🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Bug Fixes