Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#3,595 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@Lanchez ci sta già lavorando.

Dal 13/10/2026.

  • #3596 di @Lanchez — aperta

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
42/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
ios, swift
Ambito
mobile-dev, testing-qa

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
TypeScript
Stelle
5k
Fork
334
Merge medio
11h 48m
PR unite (30g)
605

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di callstack/agent-device

Tutte le issue di callstack/agent-device

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.