[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)
維護者通常 2 天內回覆
還沒有人認領這個 Issue。
評估
- 難度
- 4/5
- 預估耗時
- 3-5 天
- 新手友好度
- 45/100
研究方向
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.
由索引模型根據 Issue 內容生成。
描述
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
- Build a Release app with React Native 0.88.1 (New Architecture) and any
<Text>that hasallowFontScalingleft at its default. - Launch it on an iOS simulator or device.
- 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). - 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
-
RCTFabricSurfacehandlesUIContentSizeCategoryDidChangeNotificationby calling_updateLayoutContextwith the newfontSizeMultiplier, which reachesSurfaceHandler::constraintLayout. That commitsRootShadowNode::clone(propsParserContext, layoutConstraints, layoutContext). -
RootShadowNode::cloneonly callsdirtyLayout()when the layout constraints change:if (layoutConstraints != getConcreteProps().layoutConstraints) { newRootShadowNode->dirtyLayout(); } -
For a layout-context-only change, the root stays clean.
RootShadowNode::layoutIfNeededthen returns early (getIsLayoutClean()), solayoutTree→configureYogaTreenever runs. -
That means the existing font-scale handling in
YogaLayoutableShadowNode::configureYogaTreenever gets a chance to run, even thoughenableFontScaleChangesUpdatingLayoutdefaults totrue. That code marks measurable nodes dirty when theirfontSizeMultiplierdiffers from the new one. -
pointScaleFactorandswapLeftAndRightInRTLare consumed byconfigureYogaTreein 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.
- 主要語言
- C++
- 星號
- 127k
- 分支
- 25.5k
- 平均合併
- 3 天 18 小時
- 30 天內合併 PR
- 188
環境準備
- 沒有 Dockerfile 或 Docker Compose 檔案
- 有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue,再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫,在一個分支上完成修改。
- 送出 Pull Request,並在描述裡引用這個 Issue 編號。
react/react-native 的其他 Issue
-
難度 2/5 1-3 小時 新手友好度 76/100
react/react-native#59945 ·
維護者通常 2 天內回覆
-
難度 2/5 1-3 小時 新手友好度 82/100
react/react-native#59944 ·
維護者通常 2 天內回覆
-
難度 2/5 1-3 小時 新手友好度 78/100
react/react-native#59942 ·
維護者通常 2 天內回覆
-
難度 2/5 1-3 小時 新手友好度 76/100
react/react-native#59939 ·
維護者通常 2 天內回覆
-
難度 2/5 1-3 小時 新手友好度 78/100
react/react-native#59929 · 1 則留言 ·
維護者通常 2 天內回覆
查看 react/react-native 的全部 Issue
相似的 Issue
-
backlog
難度 2/5 1-3 小時 新手友好度 78/100
EchoTools/nevr-runtime#2385 ·
維護者通常 1 天內回覆
-
type:bug
難度 2/5 1-3 小時 新手友好度 65/100
tensorflow/tflite-micro#3995 ·
維護者通常 1 天內回覆
-
CPU update 1.31x未關閉speed-report
難度 1/5 1 小時以內 新手友好度 75/100
mw00/project-maya#961 · 1 則留言 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 78/100
-
not for AI lovers
難度 2/5 1-3 小時 新手友好度 76/100
維護者通常 1 天內回覆