ios: snapshot --observe-only can label a substituted system-alert tree as an app observation
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
调研方向
Start in RunnerTests+SnapshotExecution.swift, where the observe-only branch sets payload.observation after the ordinary capture, then check RunnerTests+Snapshot.swift to see where snapshotFast returns the SpringBoard alert tree. Choose refuse or disclose, keyed on the tier or provenance the capture returns, and reuse observeOnlyUnavailableResponse() if refusing. Done when a unit test using systemModalProbeOverrideForTesting shows an observe-only snapshot with a presented alert never carries observation, and the observe-only guarantee wording is updated.
由索引模型根据 Issue 内容生成。
描述
Follow-up to #3108 (merged 2026-10-08), from the #3106 decision.
Problem
snapshot --observe-only stamps observation (an app observation made without activating the app) on a payload that may not come from the app.
RunnerTests+SnapshotExecution.swift runs the ordinary capture first (snapshotFast / snapshotRaw), then checks only that target.app.state == .runningForeground and that the process identifier is unchanged, and then sets payload.observation. But snapshotFast (RunnerTests+Snapshot.swift) first calls boundedBlockingSystemAlertSnapshot(...) and returns the SpringBoard alert tree in place of the app's tree when one is presented. The post-capture check can still pass, because a system alert doesn't change the app's process and #2696 shows XCUIApplication.state can report foreground while another surface is in front. The result is a system-alert tree labelled as an observe-only capture of the app.
The default (non-observe-only) path is fine: it discloses the substitution through systemSurface provenance. The defect is only that the observe-only contract asserts app provenance without checking which tier produced the payload.
Required behavior
Pick one, and encode it in the observe-only branch:
- Refuse: when the capture tier substituted a system-alert or system-surface payload, return the typed observe-only-unavailable response (the existing
observeOnlyUnavailableResponse()), or - Disclose: keep the payload but omit
observationand carry the substitution provenance, so a caller can't read the payload as an app observation.
Key the decision on the tier or provenance the capture returns, not on payload contents or message text.
Done when
- A runner unit test using
systemModalProbeOverrideForTestingshows an observe-only snapshot with a presented system alert never carriesobservationalongside the alert tree. - The interaction or observation guarantee wording for observe-only states the chosen behavior.
- 主要语言
- TypeScript
- 星标
- 5.1k
- 派生
- 339
- 平均合并
- 12 小时 53 分钟
- 30 天内合并 PR
- 644
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
callstack/agent-device 的其他 Issue
-
Taps on Jetpack Compose buttons refused because of the fake Button child node可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭
难度 2/5 1-3 小时 新手友好度 78/100
callstack/agent-device#3982 ·
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 64/100
callstack/agent-device#3945 ·
维护者通常 1 天内回复
-
Limrun iOS fill reports success but drops non-ASCII text可能已有人在做 @mvanhorn 于 6 天前认领。 未关闭bug ready-for-agent
难度 2/5 1-3 小时 新手友好度 87/100
callstack/agent-device#3819 · 2 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
callstack/agent-device#1869 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 55/100
callstack/agent-device#3981 ·
维护者通常 1 天内回复
查看 callstack/agent-device 的全部 Issue
相似的 Issue
-
agent-reported area/react bug
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 82/100
Nimblesite/SharpLsp#510 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 76/100
维护者通常 1 天内回复
-
backend refactor
难度 2/5 1-3 小时 新手友好度 73/100
NIAEFEUP/tts#927 · 1 条评论 · 1 个 reaction ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 82/100
callstackincubator/react-native-harness#296 ·
维护者通常 1 天内回复