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

iOS: type/fill still reads its pre-focus element after the focus tap, ending the runner session

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

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
swift
Área
mobile-dev, testing

Línea de trabajo

Start by reading RunnerTests+TextEntryFocus.swift and RunnerTests+TextEntry.swift, then use the --agent-device-text-entry-unqueryable-on-focus fixture to identify which post-focus read records the failure. Add a regression test that drives type or fill through execute(command:) and checks for success or a typed failure reason without a recorded XCTest failure. Also verify the moved-on-focus fixture and run pnpm check:xctest-selection; done means the new test is lane-reachable and the iOS PR lane stays green.

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

Descripción

bug needs-triage

Summary

#3237 removed the post-dispatch element reads from the tap command (#3060). The report's fill @e6
row is a different seam and still fails: XCTEST_RECORDED_FAILURE "while executing type", measured at
4.5 s, separately from the tap rows at 7.7–12.8 s.

Same root mechanism — an element that stops answering the query that resolved it once it takes focus —
different owning path, so it was left out of #3237 to keep that change inside one command family.

Where the failure comes from

The type/fill focus path reads an element handle it resolved before its own focus tap, and the reads
live after the tap:

  • RunnerTests+TextEntryFocus.swift#focusTextInputForTextEntry(app:x:y:) resolves the input with
    textInputAt(app:x:y:) (line 122), dispatches a focus tap, then builds its target from
    textEntryRefreshPoint(for:), which reads element.frame (lines 140 and 160, helper at 165).
  • RunnerTests+TextEntry.swift#moveCaretToEnd(element:) reads element.frame before the caret edge-tap,
    reached from clearTextInput on a replacement fill.

.type is in the interaction group, so convertsRecordedFailure turns a recorded issue into
XCTEST_RECORDED_FAILURE, and the dispatch path invalidates the target with reason
xctest_recorded_failure. The report measured fill @e6 failing with "while executing type" in 4.5 s; it
did not measure whether that command's own focus tap landed, so this issue's premise is that the failure
comes from these reads rather than from the typing itself, which the first commit must confirm.

Which of these reads the report's fill actually reached is not established here. Measure it first: a
failed read records Failed to get matching snapshot: No matches found for … from input {(TextField)},
and safely catches an exception, so a read may also be swallowed rather than recorded.

Not in this list, because it cannot record: the witness read
safely("LAST_TAPPED_TEXT_INPUT_EXISTS", false, { element.exists }) (RunnerTests+TextEntryFocus.swift:52)
does become reachable on an unqueryable field once #3237 books the witness from pre-dispatch facts, but
exists was measured to record nothing on a handle whose element had left its query. It is a correct
fail-closed check, not part of this seam.

This is not the contained-probe path, and widening containment is not the fix: textInputAt reaches
queryTextInputs through safely, not through containingTextInputProbeIssues, and
testTextInputProbeContainmentExcludesRequiredReadsAndLaterIssues pins that a required read's failure
belongs to its caller.

Required behavior

#3237 settled this on the tap route by reading the element through snapshot() instead of
element.elementType/element.frame: the same query answer, delivered through the throwing channel,
which records nothing. Measured on a handle whose element had left its query — snapshot() records 0 and
throws 10008, where .elementType and .frame each record 1 and raise.

  • Route textEntryRefreshPoint(for:) and moveCaretToEnd(element:) through a snapshot() read for the
    type and frame they need. Where a stale frame cannot be trusted, the repo already refuses the shape:
    clearTextInput's comment says an edge-tap computed from a frame the field moved after records a
    failure or navigates away, so degrade to a route that needs no point or refuse with a typed reason
    rather than dispatching one.
  • Keep every read that must distinguish absence from failure on probeTextEntryInput, which is what tells
    a proven no-match from a read that could not answer.
  • A fill whose field genuinely did not take focus must still fail, and a genuinely recorded failure must
    still invalidate and surface. This removes reads that describe work already done, not evidence of work
    that failed.

Observable completion conditions

  • A regression test on the --agent-device-text-entry-unqueryable-on-focus fixture added in #3237 drives
    type/fill through execute(command:) and asserts the command succeeds or fails with a typed reason
    and that didRecordXCTestFailure(since:) is false. It must be red before the change, showing which read
    records the issue.
  • --agent-device-text-entry-moves-on-focus still passes: a refresh point carried from a pre-focus
    identity must not retarget a field that moved, which is what TextInputAtPoint.identity and a target's
    boundIdentity already guard.
  • pnpm check:xctest-selection keeps every new case reachable by a lane, and the iOS PR lane stays green.

Dependencies

  • Prerequisite: #3237 (the tap-side fix, and the fixture this issue's test builds on).
  • Related: #3060 (the report), #1599 (narrow-issue policy), #2273 (a failed selector query
    indistinguishable from a true negative), #1605 (tap-failure corroboration).

Not in scope

Daemon tap-failure corroboration still compares an identity that includes the unstable element type, so
ios_tap_failure_corroboration_identity_mismatch remains the outcome whenever any seam records a tap
failure. That is the report's second ask and needs its own change to
src/daemon/interaction/internal/interaction-ios-tap-outcome.ts; do not fold it in here.

Line numbers above are as of a6f6af1 in #3237, which added a doc comment to RunnerTests+TextEntryFocus.swift and shifted them by a few lines. moveCaretToEnd is RunnerTests+TextEntry.swift:398 there.

Lenguaje dominante
TypeScript
Estrellas
4.9k
Forks
328
Merge medio
12 h 19 min
PR fusionados (30 d)
549

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.