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

Đang mở
  • Có gì không ổn?
#59,927 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 2 ngày

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
45/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
cpp, ios, react-native
Lĩnh vực
frontend, mobile

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
C++
Star
127k
Fork
25.5k
Merge trung bình
3 ngày 18 giờ
Pull request đã merge (30 ngày)
188

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. 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.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của react/react-native

Tất cả issue của react/react-native

Issue tương tự

Thêm issue về C++

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.