react / react/react-native

[iOS][Fabric] RTL horizontal ScrollView: contentOffset prop is not RTL-converted while scrollTo/metrics are, and scrollTo conversion uses stale contentSize

Ouverte
#58,534 3 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Needs: Attention Needs: Repro
Langage dominant
C++
Étoiles
127k
Forks
25.3k
Merge moyen
1 j 23 h
PR mergées (30 j)
4

Description

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: applies CGAffineTransformMakeScale(-1, 1) to _containerView and _scrollView when layoutDirection == RightToLeft.
  • _scrollViewMetrics converts 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 the contentOffset prop with no conversion: _scrollView.contentOffset = RCTCGPointFromPoint(newScrollViewProps.contentOffset)main ~L408. The prepareForRecycle / state-restore paths set contentOffset unconverted too.

Two concrete consequences:

  1. Prop vs. imperative disagree. In RTL, contentOffset={{x: k * pageWidth}} positions the view in physical (mirrored) space, while scrollTo({x: k * pageWidth}) positions it in logical space (and onScroll reports logical). For a paged list the prop lands one page off / at the far end relative to an identical scrollTo.
  2. scrollTo is timing-dependent. The conversion uses self.contentSize.width and _scrollView.frame.size.width at call time. A scrollTo issued right after content changes (before the native contentSize commits — e.g. in a setTimeout(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

  1. RTL app: I18nManager.allowRTL(true); I18nManager.forceRTL(true) and cold launch (the direction is read at startup).
  2. newArchEnabled: true, iOS.
  3. Horizontal ScrollView with pagingEnabled, N full-width pages.
  4. Case A — set contentOffset={{x: k * width}} as a prop; compare the page shown with calling scrollTo({x: k * width, animated: false}) after mount: they show different pages.
  5. Case B — change the content (add/remove pages) and in the same tick / setTimeout(0) call scrollTo({x: k * width}): on a device it frequently lands on a different page than k (converted against the previous contentSize); reading contentOffset.x from the next onScroll confirms 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.

Guide de contribution

Ouvrir le guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Piste de recherche

Commencez dans React/Fabric/Mounting/ComponentViews/ScrollView/RCTScrollViewComponentView.mm, en comparant updateProps:, prepareForRecycle, la restauration de l’état, scrollToOffset:animated: et _scrollViewMetrics. Utilisez les étapes de reproduction RTL Fabric indiquées pour observer les offsets des props et les offsets impératifs avant et après les modifications du contenu. Le travail est considéré comme terminé lorsque les entrées d’offset RTL se comportent de manière cohérente et que le timing de la taille du contenu ne provoque plus de décalages de page non documentés, le comportement concerné étant couvert ou clairement documenté.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Évaluation

Stack technique
ios, objective-c
Domaine
mobile-dev
Type d'issue
Bug
Difficulté
4/5
Temps estimé
3-5 jours
Activité
Active
Clarté
Plutôt claire
Accessibilité débutants
42/100

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.