[iOS][Fabric] Changing Dynamic Type while the app is running does not re-lay out text (root not dirtied on a layout-context-only change)

Ouverte
  • Quelque chose ne va pas ?
#59,927 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 2 jours

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
45/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
cpp, ios, react-native
Domaine
frontend, mobile

Piste de recherche

Start with RootShadowNode.cpp and inspect RootShadowNode::clone, then follow layoutContext into YogaLayoutableShadowNode::configureYogaTree. The issue identifies the three layout-context inputs that need to trigger layout dirtiness and explains why comparing the full context would be too broad. Reproduce the Dynamic Type change on iOS with the New Architecture, then verify existing layout tests cover the context changes and that text relays out after the change.

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

Description

Needs: Author Feedback Needs: Repro
Description

On iOS with the New Architecture, changing the system text size (Dynamic Type) while the app is running has no visible effect on text already on screen. React Native receives the new fontSizeMultiplier, but no layout pass runs, so text keeps its launch-time size until the app is restarted. Text mounted after the change can pick up the new size, which produces mixed layouts.

Steps to reproduce
  1. Build a Release app with React Native 0.88.1 (New Architecture) and any <Text> that has allowFontScaling left at its default.
  2. Launch it on an iOS simulator or device.
  3. Without closing the app, change the text size (Settings › Display & Brightness › Text Size, or on a simulator xcrun simctl ui <udid> content_size accessibility-extra-large).
  4. Return to the app.

Expected: text re-lays out at the new size.
Actual: nothing changes, in either direction. Relaunching renders the new size correctly.

Root cause

  • RCTFabricSurface handles UIContentSizeCategoryDidChangeNotification by calling _updateLayoutContext with the new fontSizeMultiplier, which reaches SurfaceHandler::constraintLayout. That commits RootShadowNode::clone(propsParserContext, layoutConstraints, layoutContext).

  • RootShadowNode::clone only calls dirtyLayout() when the layout constraints change:

    if (layoutConstraints != getConcreteProps().layoutConstraints) {
  newRootShadowNode->dirtyLayout();
}

  • For a layout-context-only change, the root stays clean. RootShadowNode::layoutIfNeeded then returns early (getIsLayoutClean()), so layoutTree → configureYogaTree never runs.

  • That means the existing font-scale handling in YogaLayoutableShadowNode::configureYogaTree never gets a chance to run, even though enableFontScaleChangesUpdatingLayout defaults to true. That code marks measurable nodes dirty when their fontSizeMultiplier differs from the new one.

  • pointScaleFactor and swapLeftAndRightInRTL are consumed by configureYogaTree in the same way, so a change to either alone has the same problem.

The same code is on main as of 2026-11-10 (RootShadowNode.cpp last changed in 178c30d7ac). #59285 makes ParagraphShadowNode drop content built for another fontSizeMultiplier, but that only helps once a layout pass actually runs.

Proposed fix

Dirty the root when any layout-context input that configureYogaTree consumes changes:

-  if (layoutConstraints != getConcreteProps().layoutConstraints) {
+  const auto& previousContext = getConcreteProps().layoutContext;
+  if (layoutConstraints != getConcreteProps().layoutConstraints ||
+      layoutContext.fontSizeMultiplier != previousContext.fontSizeMultiplier ||
+      layoutContext.pointScaleFactor != previousContext.pointScaleFactor ||
+      layoutContext.swapLeftAndRightInRTL !=
+          previousContext.swapLeftAndRightInRTL) {
     newRootShadowNode->dirtyLayout();
   }

The full LayoutContext == is deliberately not used: it also compares affectedNodes (a per-pass pointer) and the viewport fields, which would dirty the root on unrelated commits.

I traced this in source and reproduced the symptom in a Release build. I have not run the patched build myself, because our app uses the prebuilt React Native core.

Versions

React Native 0.88.1 (also present on 0.88-stable and main), Expo SDK 58, iOS 26.5 simulator, New Architecture, Hermes.

Langage dominant
C++
Étoiles
127k
Forks
25.5k
Merge moyen
3 j 18 h
PR mergées (30 j)
188

Préparer son environnement

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.

Autres issues de react/react-native

Toutes les issues de react/react-native

Issues similaires

Plus d'issues C++

Recevez les nouvelles issues par e-mail

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