[iOS] Main-thread hang in PageChildViewController.propagateSafeArea when UIKit doesn't apply additionalSafeAreaInsets (9.0.7–10.0.0)
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 55/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- ios, react-native, swift
- 领域
- mobile, performance
调研方向
Start with ios/Extensions.swift, especially PageChildViewController.propagateSafeArea() and the callbacks shown in the stack trace. Review how additionalInsets(toReach:) uses safeAreaInsets, then reproduce the described zoom push and pop sequence and check whether repeated writes stop when UIKit leaves the safe area unchanged. Done means the main-thread hang is prevented while normal safe-area propagation still works.
由索引模型根据 Issue 内容生成。
描述
Summary
On iOS, PageChildViewController.propagateSafeArea() in ios/Extensions.swift can loop forever on the main thread. The app stops responding, one core stays at 100%, and the iOS watchdog kills it (0x8BADF00D, either scene-update or failed-to-terminate). We see this in production TestFlight builds on 9.0.7. 9.0.11 and 10.0.0 ship the same propagateSafeArea.
Environment
| Component | Version |
|---|---|
| react-native-pager-view | 9.0.7 (same code in 9.0.11 and 10.0.0) |
| React Native | 0.88.0, Fabric |
| React | 19.3.0 |
| Expo / Expo Router | 58.0.17 / 58.0.25 |
| react-native-screens | 4.30.0 |
| Device | iPhone 16 on iOS 27.0.1; also reproduced on an iOS 27.2 Simulator |
Setup and trigger
The screen is a horizontal PagerView with three tabs, each holding a vertical list. A sticky header above the pager hides on scroll by animating translateY on the pager's container, so the pager slides up under the status bar. Tapping a list item pushes a native-stack screen with an iOS 18+ zoom transition (expo-router Link.AppleZoom). The freeze reproduces within about six cycles of: scroll the list, open an item, go back, scroll again. It happens right after going back while the header slides away.
What the loop does
Main-thread sample from the frozen Simulator app (Debug build):
PageChildViewController.viewDidLayoutSubviews() Extensions.swift:35
PageChildViewController.propagateSafeArea() Extensions.swift:64 (additionalSafeAreaInsets = insets)
-[UIViewController _updateContentOverlayInsetsForSelfAndChildren]
... -[UIView _safeAreaInsetsDidChangeFromOldInsets:]
PageChildViewController.viewSafeAreaInsetsDidChange() Extensions.swift:40
PageChildViewController.propagateSafeArea() Extensions.swift:64
... (nested again and again, then the next layout pass starts over)
At Extensions.swift:64, lldb on the same page controller shows this on every pass:
viewInWindow = {{0, 36.89}, {402, 854}} -> target top = 62 - 36.89 ≈ 25.1
view.safeAreaInsets = {62, 0, 51, 0} (never changes)
additionalSafeAreaInsets = {-152846256.6, 0, 36.77, 0}
{-152846293.5, 0, 36.99, 0}
{-152846330.4, 0, 36.88, 0} ... (−36.9 per write, forever)
additionalInsets(toReach:) derives the inherited inset as view.safeAreaInsets - additionalSafeAreaInsets, which assumes UIKit applied the last write. Here UIKit does not apply additionalSafeAreaInsets to this page at all, so view.safeAreaInsets stays at 62. Each pass therefore computes new = current + (target - 62), which moves the value by the same −36.9 pt every time. The > 0.5 "changed?" check is always true, so the write and its callbacks never stop. We don't know why UIKit stops applying the insets for this page. It only shows up after the zoom push and pop.
Before 9.x (8.0.2, UIViewRepresentable) this screen did not hang.
Patch we ship
This makes propagateSafeArea ignore its own nested callback, and write again only when the target or the page's actual safe area moved since its last write. In the normal case the first write lands and later passes have nothing to change, so behavior is unchanged. In the broken state it writes once and stops. With it, the same repro ran 20 cycles without a freeze. During 8 of those cycles, lldb counted 10 writes the new check skipped; without the patch, each of those would have started the endless loop.
@@ -21,6 +21,8 @@ struct RepresentableView: UIViewControllerRepresentable {
class PageChildViewController: UIViewController {
var wrappedView: UIView?
+ private var isPropagatingSafeArea = false
+ private var lastSafeAreaWrite: (target: UIEdgeInsets, safeArea: UIEdgeInsets)?
override func viewDidLoad() {
super.viewDidLoad()
@@ -55,14 +57,37 @@ class PageChildViewController: UIViewController {
/// Do not walk to the nearest ancestor with a non-zero inset. That source
/// is in the ancestor's own coordinate space and can track scroll offset
/// (#1099).
+ ///
+ /// `additionalInsets(toReach:)` assumes UIKit applies the value written
+ /// here. A page re-hosted by a zoom transition can keep a fixed
+ /// `safeAreaInsets` instead, so every pass subtracts the same gap again and
+ /// the main thread loops forever. Write only when the target or the page's
+ /// safe area moved since the last write.
private func propagateSafeArea() {
- let insets = additionalInsets(toReach: targetSafeAreaInsets())
- if abs(additionalSafeAreaInsets.top - insets.top) > 0.5
- || abs(additionalSafeAreaInsets.left - insets.left) > 0.5
- || abs(additionalSafeAreaInsets.bottom - insets.bottom) > 0.5
- || abs(additionalSafeAreaInsets.right - insets.right) > 0.5 {
- additionalSafeAreaInsets = insets
+ guard !isPropagatingSafeArea else {
+ return
+ }
+ let target = targetSafeAreaInsets()
+ let insets = additionalInsets(toReach: target)
+ if Self.insetsMatch(additionalSafeAreaInsets, insets) {
+ return
+ }
+ if let lastWrite = lastSafeAreaWrite,
+ Self.insetsMatch(lastWrite.target, target),
+ Self.insetsMatch(lastWrite.safeArea, view.safeAreaInsets) {
+ return
}
+ isPropagatingSafeArea = true
+ additionalSafeAreaInsets = insets
+ isPropagatingSafeArea = false
+ lastSafeAreaWrite = (target: target, safeArea: view.safeAreaInsets)
+ }
+
+ private static func insetsMatch(_ lhs: UIEdgeInsets, _ rhs: UIEdgeInsets) -> Bool {
+ abs(lhs.top - rhs.top) <= 0.5
+ && abs(lhs.left - rhs.left) <= 0.5
+ && abs(lhs.bottom - rhs.bottom) <= 0.5
+ && abs(lhs.right - rhs.right) <= 0.5
}
private func additionalInsets(toReach target: UIEdgeInsets) -> UIEdgeInsets {
We're happy to open a PR with this if the approach looks right, or to test another fix.
- 主要语言
- TypeScript
- 星标
- 3.4k
- 派生
- 491
- 平均合并
- 2 天 4 小时
- 30 天内合并 PR
- 51
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
callstack/react-native-pager-view 的其他 Issue
-
[iOS] UIKit's scroll to a focused field can leave the pager between pages可能已有人在做 @TaduJR 于 2 天前认领。 未关闭
难度 4/5 3-5 天 新手友好度 52/100
callstack/react-native-pager-view#1230 · 4 条评论 ·
维护者通常 1 天内回复
-
[iOS] setPage does not animate when the pager resizes with the keyboard可能已有人在做 @TaduJR 于 4 天前认领。 未关闭
难度 4/5 3-5 天 新手友好度 52/100
callstack/react-native-pager-view#1223 · 3 条评论 ·
维护者通常 1 天内回复
-
Resolution: Needs Repro
难度 4/5 3-5 天 新手友好度 32/100
callstack/react-native-pager-view#1222 · 2 条评论 · 1 个 reaction ·
维护者通常 1 天内回复
-
难度 3/5 1-2 天 新手友好度 58/100
callstack/react-native-pager-view#1189 ·
维护者通常 1 天内回复
-
iOS: PagerScrollDelegate proxies to itself and overflows the stack when the weak originalDelegate dies可能已有人在做 @lvlrSajjad 于 56 天前认领。 未关闭
难度 4/5 3-5 天 新手友好度 25/100
callstack/react-native-pager-view#1146 ·
维护者通常 1 天内回复
查看 callstack/react-native-pager-view 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 74/100
earendil-works/pi-claude-code#36 ·
维护者通常 6 天内回复
-
难度 2/5 1-3 小时 新手友好度 65/100
维护者通常 1 天内回复
-
Resources: New work of jabodetabek可能已有人在做 @rmt-svc 今天认领。 未关闭resources
难度 2/5 1-3 小时 新手友好度 62/100
railmapgen/rmp-gallery#4167 ·
维护者通常 2 天内回复
-
documentation p1
难度 2/5 1-3 小时 新手友好度 75/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 83/100
microsoft/monaco-editor#5577 ·
维护者通常 1 天内回复