Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#3,595 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@Lanchez arbeitet bereits daran.

Seit 13.10.2026.

  • #3596 von @Lanchez — offen

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
42/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
ios, swift
Bereich
mobile-dev, testing-qa

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
TypeScript
Sterne
5k
Forks
334
Ø Merge
11 Std. 48 Min.
Gemergte PRs (30 T.)
605

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus callstack/agent-device

Alle Issues in callstack/agent-device

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.