[iOS][Fabric] RTL horizontal ScrollView: contentOffset prop is not RTL-converted while scrollTo/metrics are, and scrollTo conversion uses stale contentSize
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 42/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- ios, objective-c
- Lĩnh vực
- mobile-dev
Hướng nghiên cứu
Bắt đầu trong React/Fabric/Mounting/ComponentViews/ScrollView/RCTScrollViewComponentView.mm, so sánh updateProps:, prepareForRecycle, việc khôi phục state, scrollToOffset:animated: và _scrollViewMetrics. Sử dụng các bước tái hiện RTL Fabric được liệt kê để quan sát các offset của prop và các offset imperative trước và sau khi nội dung thay đổi. Được xem là hoàn thành khi các đầu vào offset RTL hoạt động nhất quán và thời điểm kích thước nội dung không còn gây ra các sai lệch trang không được ghi lại, với hành vi liên quan được bao phủ hoặc ghi lại rõ ràng.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Description
On the New Architecture (Fabric), iOS implements RTL for a horizontal ScrollView by mirroring the view and converting scroll coordinates — but the conversion is asymmetric, and the imperative conversion depends on the native contentSize being current at call time. JS-driven paged lists that work on Paper break on Fabric under RTL.
In React/Fabric/Mounting/ComponentViews/ScrollView/RCTScrollViewComponentView.mm (0.81.5; the same code is on main and 0.82-stable):
updateLayoutMetrics:appliesCGAffineTransformMakeScale(-1, 1)to_containerViewand_scrollViewwhenlayoutDirection == RightToLeft._scrollViewMetricsconverts the reported offset:metrics.contentOffset.x = contentSize.width - containerSize.width - contentOffset.x(RTL branch).scrollToOffset:animated:converts the requested offset:offset.x = self.contentSize.width - _scrollView.frame.size.width - offset.x(RTL branch) —main~L1024.updateProps:applies thecontentOffsetprop with no conversion:_scrollView.contentOffset = RCTCGPointFromPoint(newScrollViewProps.contentOffset)—main~L408. TheprepareForRecycle/ state-restore paths setcontentOffsetunconverted too.
Two concrete consequences:
- Prop vs. imperative disagree. In RTL,
contentOffset={{x: k * pageWidth}}positions the view in physical (mirrored) space, whilescrollTo({x: k * pageWidth})positions it in logical space (andonScrollreports logical). For a paged list the prop lands one page off / at the far end relative to an identicalscrollTo. scrollTois timing-dependent. The conversion usesself.contentSize.widthand_scrollView.frame.size.widthat call time. AscrollToissued right after content changes (before the nativecontentSizecommits — e.g. in asetTimeout(0)after a data update, a very common pattern) is converted with stale dimensions and lands on the wrong page. This never happened in LTR (no conversion) and did not happen on Paper, so it surfaces as intermittent, device-only page jumps.
Steps to reproduce
- RTL app:
I18nManager.allowRTL(true); I18nManager.forceRTL(true)and cold launch (the direction is read at startup). newArchEnabled: true, iOS.- Horizontal
ScrollViewwithpagingEnabled, N full-width pages. - Case A — set
contentOffset={{x: k * width}}as a prop; compare the page shown with callingscrollTo({x: k * width, animated: false})after mount: they show different pages. - Case B — change the content (add/remove pages) and in the same tick /
setTimeout(0)callscrollTo({x: k * width}): on a device it frequently lands on a different page thank(converted against the previouscontentSize); readingcontentOffset.xfrom the nextonScrollconfirms the mismatch.
Expected behavior
All offset inputs are converted consistently in RTL — the contentOffset prop (and recycle/state restore) using the same mapping as scrollToOffset: and _scrollViewMetrics — and the imperative conversion should not silently use a stale contentSize (or the behavior should be documented so libraries can wait for the commit).
React Native Version
0.81.5 (Expo SDK 54). Verified the same code paths on main and 0.82-stable.
Affected Platforms
Runtime - iOS (New Architecture / Fabric). Not reproducible on the old architecture; not affected in LTR.
Environment
macOS 15 (Darwin 24.2), Xcode 16.2, iPhone 12 simulator (iOS 18.2) and physical iPhone (iOS 26.3.1), Hermes, newArchEnabled: true.
Real-world impact
react-native-calendars (used widely for RTL calendars) implements its own RTL offset handling for its recyclerlistview-based horizontal pagers; on Fabric that handling — and a naive "just remove the inversion" fix — both fail because of the two points above, producing calendars that jump between days/weeks nonstop. A downstream workaround (keep the pager's container direction: 'ltr' and mirror in JS) will be linked here.
Reproducer
No standalone reproducer repository attached yet; the steps above are minimal and the relevant native lines are cited. Happy to add a reproducer-react-native repo if maintainers want one.
- Ngôn ngữ chính
- C++
- Star
- 127k
- Fork
- 25.3k
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của react/react-native
-
Needs: Author Feedback Needs: Repro
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 92/100
react/react-native#58621 · 1 bình luận ·
-
Needs: Author Feedback Needs: Repro
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
react/react-native#58610 · 1 bình luận ·
-
Needs: Triage :mag:
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
react/react-native#58565 · 1 bình luận · 2 reaction ·
-
Needs: Author Feedback Needs: Repro
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
react/react-native#58555 · 4 bình luận · 1 reaction ·
-
Needs: Attention Needs: Repro
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
react/react-native#58526 · 2 bình luận ·
Tất cả issue của react/react-native
Issue tương tự
-
enhancement
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
QuantStack/git2cpp#187 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 86/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
mlcommons/mobile_app_open#1182 ·
-
Needs-Triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
microsoft/winget-cli#6547 ·
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 90/100
AXERA-TECH/ax-llm#77 ·