Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

iOS: fill rejects the right text as `TEXT_ENTRY_MISMATCH` when the focused field moves while typing (since 0.21.25)

未关闭
  • 哪里不对？
#3,595 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

@Lanchez 已经在做这个了。

开始于 2026年10月13日。

  • #3596 来自 @Lanchez —— 未关闭

评估

难度
3/5
预计耗时
1-2 天
新手友好度
42/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
ios, swift
领域
mobile-dev, testing-qa

调研方向

Start in RunnerTests+TextEntryConfirmation.swift at replacementTextEntryResult, where verified is set to false when the baseline and read-back fail isSameElement. Check how snapshotHasFocus is recorded and how verificationStabilityWindow is used. Done means a fill whose focused, identifier-less field only moves in frame and reads back the exact text verifies, while other changed-frame read-backs still fail TEXT_ENTRY_MISMATCH. The issue names no test file, so find the existing text-entry tests before adding cases.

由索引模型根据 Issue 内容生成。

描述

What happens

fill into an empty field fails although the field ends up holding exactly the requested text:

Error (TEXT_ENTRY_MISMATCH): text entry read-back did not match: expected "qxzqxzqxz", observed "qxzqxzqxz"

It happens when the field has no accessibility identifier and moves while the text goes in. Our case is a React Native app's iOS 26+ bottom search bar (react-native-screens headerSearchBarOptions, a UISearchController): it is focused and docked at the bottom before typing, and rises above the keyboard and widens once the first characters arrive. The app cannot give this field an identifier: react-native-screens 4.26.2's SearchBarProps has no testID, and its native search bar sets no accessibilityIdentifier, so a script can only address it by label, ref or coordinates.

Why

replacementTextEntryResult (RunnerTests+TextEntryConfirmation.swift) returns verified: false before comparing values when the baseline and the read-back are not isSameElement, and for an element without an identifier that means the same type at the exact same frame. 0.21.25 introduced this read-back (#3334); 0.21.24 passes the same fills.

What the runner read, logged inside replacementTextEntryResult for a failing fill (iPhone Air simulator, iOS 26.5):

baseline = SearchField (88, 836, 244 × 48), value "", hasKeyboardFocus true
observed = SearchField (8, 548, 348 × 48), value "qxzqxzqxz", hasKeyboardFocus true

The baseline does not catch the field mid-animation. We tried a baseline that waits until value and identity stay unchanged for verificationStabilityWindow before typing: it settled in 230–260 ms on every fill, so the field was still, and the fills still failed 20/20. The field moves only after typing starts.

Reproduction

The first search fill after each app launch, on an iPhone Air simulator, iOS 26.5:

agent-device open <app> --udid <udid> --session s --relaunch
agent-device open "<deep link to a screen with the search tab>" --session s
agent-device press 'role=button label="Search"' --session s
agent-device wait 'label="Search" editable=true' 5000 --session s
agent-device wait stable 300 5000 --session s
agent-device fill 'label="Search" editable=true' "qxzqxzqxz" --session s

On main at 352ad624d, 10 relaunches with two search fills each, that simulator alone: 20/20 first attempts failed; a retry in the same launch passed. The same run on three simulators at once gave the same 20/20 on the iOS 26.5 iPhone Air, while an iPhone 16 on iOS 18.5, whose search bar does not move, passed 20/20. Whether an iOS 27.0 iPhone Air fails varies with simulator state: it failed every first fill after an earlier long run and none after a cold boot.

macOS 27.0.1, Xcode 27.0 (27A266a), Node 24.21.0, runtimes iOS 26.5 (23F77) and iOS 27.0 (24A434).

Required behavior

A replacement fill whose read-back holds exactly the requested text, in a field that held focus before and after the entry, verifies even when that field's frame changed. Any other read-back at a changed frame still fails as it does now.

Proposed fix

Record whether the field held focus at each read (the existing snapshotHasFocus). When the baseline and the read-back differ only in frame, both without an identifier, of the same type and both focused, verify the fill if the read-back is exactly the requested text, and fail it otherwise, as now. Element identity and the settle check stay frame-strict.

Focus alone does not tell a moved field from an unidentified field that replaced it at the same query index, which is why this admits only an exact read-back. A successor that ends up holding exactly the requested text would still verify; that is the remaining gap.

主要语言
TypeScript
星标
5k
派生
334
平均合并
11 小时 48 分钟
30 天内合并 PR
605

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

callstack/agent-device 的其他 Issue

查看 callstack/agent-device 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。