iOS fill can report TEXT_ENTRY_MISMATCH before the confirmation deadline
维护者通常 1 天内回复
已经有一个关联 PR 被合并了。
- #3953 来自 @shamilovtim —— 已合并
评估
- 难度
- 3/5
- 预计耗时
- 1-2 天
- 新手友好度
- 35/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 停滞
- 技术栈
- ios, testing-qa, typescript
调研方向
Read RunnerTests+TextEntryConfirmation.swift and inspect the ReplacementTextEntryConfirmation polling rule. Run or add the synthetic regression described in the issue for transient partial text, a moved empty field, later exact success, and persistent mismatch. Done means negative observations keep polling within the existing deadline while the stated early success, identity, and mismatch behaviors remain intact; linked pull request #3953 is already open.
由索引模型根据 Issue 内容生成。
描述
Bug
On the iOS accessibility-driven fill route, replacement confirmation can return verified: false before its existing confirmation deadline. The caller then reports TEXT_ENTRY_MISMATCH, even though a subsequent read within that deadline can contain the requested text.
This is a source-level, synthetic reproduction against 45125d717b207736dd47bc7969edbff7807a6e6d; it does not depend on a particular application.
Deterministic reproduction
Exercise ReplacementTextEntryConfirmation with requested text 123456, an empty baseline, and timestamps relative to initialization:
| Time | Observation | Expected |
|---|---|---|
| 0.10 s | 123 on the same identified input |
Pending |
| 0.31 s | 123 on that input |
Pending |
| 0.50 s | 123456 on that input |
Pending while settling |
| 0.71 s | 123456 on that input |
Verified |
Currently the second observation returns verified: false, so the caller stops before the later correct observation. The same early rejection occurs for an empty, focused, unidentified field whose frame changed from its baseline.
Cause
In RunnerTests+TextEntryConfirmation.swift, settled && (moved || result.verified != false || sampledAt >= deadline) permits a settled negative result whenever the observation differs from its baseline. A changed partial value or changed field frame satisfies moved; neither proves that a negative observation is final.
Required behavior
- Keep polling negative replacement observations within the existing bounded confirmation budget.
- Preserve early settled exact/unconfirmed results and identity protections.
- Preserve rejection when a mismatch persists through the deadline.
- Type once; do not clear, retype, or add mutation retries.
Completion: a synthetic regression must fail on the current rule and pass after correction, including transient partial text, a moved empty field, later exact success, and persistent mismatch rejection. No public API change or new dependency is needed.
- 主要语言
- TypeScript
- 星标
- 5.1k
- 派生
- 339
- 平均合并
- 12 小时 53 分钟
- 30 天内合并 PR
- 644
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
callstack/agent-device 的其他 Issue
-
A session bound to an Apple device rejects --device=<its own UDID>可能已有人在做 @zerone0x 今天认领。 未关闭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 天内回复
-
Android: snapshot helper exits without parseable output after a screen transition (still on 0.21.33)未关闭
难度 4/5 3-5 天 新手友好度 45/100
callstack/agent-device#4005 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 48/100
callstack/agent-device#3992 ·
维护者通常 1 天内回复
查看 callstack/agent-device 的全部 Issue
相似的 Issue
-
calcite-ui-icons enhancement impact - p3 - not time sensitive needs triage
难度 2/5 1-3 小时 新手友好度 67/100
Esri/calcite-design-system#15467 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
diegosouzapw/OmniRoute#18390 ·
-
难度 2/5 1-3 小时 新手友好度 65/100
-
难度 1/5 1-3 小时 新手友好度 86/100
guilhermerodz/input-otp#157 · 1 条评论 ·
-
难度 2/5 1-3 小时 新手友好度 82/100
davidjerleke/embla-carousel#1414 ·
维护者通常 4 天内回复