[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 天内回复