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

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

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

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
swift
Ambito
mobile-dev, testing

Direzione di ricerca

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.

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

Descrizione

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.

Lingua principale
TypeScript
Stelle
4.9k
Fork
328
Merge medio
12h 19m
PR unite (30g)
549

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.