Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Cerrado
  • ¿Algo no está bien?
#3,595 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Ya se ha fusionado un pull request relacionado.

  • #3596 de @Lanchez — fusionado

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
42/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
ios, swift
Área
mobile-dev, testing-qa

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
5k
Forks
334
Merge medio
13 h 19 min
PR fusionados (30 d)
630

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de callstack/agent-device

Todos los issues de callstack/agent-device

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.