[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)

Abierto
  • ¿Algo no está bien?
#59,927 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
cpp, ios, react-native
Área
frontend, mobile

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
C++
Estrellas
127k
Forks
25.5k
Merge medio
3 d 18 h
PR fusionados (30 d)
188

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de react/react-native

Todos los issues de react/react-native

Issues similares

Más issues de C++

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.