iOS: clear and fill on a field over 120 characters leave old text behind (`estimatedDeleteCount` caps at 120)
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 3/5
- 预计耗时
- 1-2 天
- 新手友好度
- 76/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- ios, typescript
调研方向
Start in RunnerTests+TextEntry.swift and read clearTextInput and estimatedDeleteCount; then inspect the repair call in RunnerTests+TextTyping.swift. Reproduce with a 501-character value and verify that clear leaves the field empty and fill replaces the old value. The issue suggests bounding repeated delete bursts and using the existing single-burst behavior when the value cannot be read.
由索引模型根据 Issue 内容生成。
描述
On iOS, fill <target> "" and fill <target> "<text>" delete at most 120 characters of the existing value. A longer value is only partly cleared, so a clear leaves text behind and a fill appends to the leftover instead of replacing it.
Reproduce
- A SwiftUI
TextEditor(or any text field) holding 501 characters. fill <field> "": 381 characters remain.- Put 501 characters back, then
fill <field> "<500 chars>": the field ends at 1261 characters and the fill fails text entry verification.
Seen on agent-device 0.21.28, iOS 26.5 simulator. The same code is on main (e35d8de8).
Cause
RunnerTests+TextEntry.swift:
private func estimatedDeleteCount(for element: XCUIElement) -> Int {
let valueText = normalizedElementText(element.value)
let base = valueText.isEmpty ? 24 : (valueText.count + 8)
return max(24, min(120, base))
}
clearTextInput sends that many delete keys once and never checks whether the field is empty afterwards. With 501 characters:
- clear: 501 - 120 = 381 left
- fill: 381 + 500 = 881, then the repair in
RunnerTests+TextTyping.swift(clearTextInput(app: app, repairTarget)beforetypeText(expectedText)) deletes another 120 and retypes 500: 881 - 120 + 500 = 1261
Suggested fix
In clearTextInput, re-read the value after each delete burst and keep going until it reads empty, with a bounded number of rounds so a field that never reports its value can't loop forever. Size each burst from the value just read (keep a per-burst cap if long typeText strings are slow). When the value can't be read (secure fields, bullet-only values), fall back to the current single burst, or to select-all then delete.
- 主要语言
- TypeScript
- 星标
- 5.1k
- 派生
- 339
- 平均合并
- 12 小时 23 分钟
- 30 天内合并 PR
- 730
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
callstack/agent-device 的其他 Issue
-
bug ready-for-agent
难度 2/5 1-3 小时 新手友好度 87/100
callstack/agent-device#3819 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
callstack/agent-device#1869 ·
维护者通常 1 天内回复
-
feat(hardware-button): press phone volume and power buttons on Android and iOS可能已有人在做 @thymikee 今天认领。 未关闭needs-triage
难度 5/5 一周以上 新手友好度 25/100
callstack/agent-device#3848 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 35/100
callstack/agent-device#3844 ·
维护者通常 1 天内回复
-
press/click: refuse a zero-area target instead of tapping its origin可能已有人在做 @faresrafat3 于 1 天前认领。 未关闭bug ready-for-agent
难度 2/5 1-3 小时 新手友好度 20/100
callstack/agent-device#3841 ·
维护者通常 1 天内回复
查看 callstack/agent-device 的全部 Issue
相似的 Issue
-
frontend
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 86/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 75/100
ranxianglei/billion-context#4172 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 75/100
awslabs/threat-composer#362 ·
维护者通常 1 天内回复
-
Area/Cloud Needs Triage Type/Bug
难度 1/5 1-3 小时 新手友好度 86/100
wso2/product-integrator#2847 ·
维护者通常 1 天内回复