Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

iOS: tapping a Flutter password field records an XCTest failure and restarts the runner, although the tap lands

Open
#3,060 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
57/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
flutter, ios

Research direction

Reproduce the sequence with agent-device open, snapshot -i --force-full, and click @e6, then inspect the runner's post-dispatch lookup and tap-failure corroboration path described in the logs. Compare the password-field behavior with the email field and verify that a landed tap no longer returns XCTEST_RECORDED_FAILURE or invalidates the runner session.

Written by the indexing model from the issue text.

Description

Summary

On the iOS Simulator, every tap on a Flutter password field returns XCTEST_RECORDED_FAILURE.

The tap lands. The field takes focus, and a following type enters the text.

But the failure invalidates the runner session. Each tap then costs 7 to 14 seconds instead of under 1 second. The tap-failure corroboration from #1605 runs, and then rejects the tap with ios_tap_failure_corroboration_identity_mismatch.

#1599 asks for a narrow issue when a current sequence reproduces this failure, so here is one.

Version

  • agent-device 0.21.15, both CLI and daemon.
  • macOS host, iPhone 17 simulator on the iOS 26.0 runtime. The runner is built against iphonesimulator26.5.
  • The app is a Flutter app. Its login screen has an email TextField and a password TextField with obscureText: true.

I have not run this on 0.21.16. The commits in v0.21.15...v0.21.16 do not touch tap corroboration or the runner's post-tap lookup.

Steps

agent-device open <flutter-app> --relaunch --platform ios
agent-device snapshot -i --force-full
# @e5 [text-field] "Email" [editable]
# @e6 [text-field] "Password" [editable]
agent-device click @e6 --json

What we measured

All commands ran on the same login screen, each from a fresh relaunch.

command result duration
click @e5 (email field) ok 0.7 to 1.2 s
click @e6 (password field), keyboard down XCTEST_RECORDED_FAILURE 12.8 s
click @e6 XCTEST_RECORDED_FAILURE 7.7 to 8.5 s
press 201 406 (centre of the password field) XCTEST_RECORDED_FAILURE 7.1 s
fill @e6 <text> XCTEST_RECORDED_FAILURE ("while executing type") 4.5 s

Two runs of our agent hit the same failure on this screen, costing 13.8 s and 7.5 s.

The result does not depend on the keyboard. It fails with the keyboard down and after typing into the email field. The email field on the same screen taps normally.

The tap lands

After a failed click @e6, type abc123 returns Typed 6 chars. A screenshot then shows the password field focused, with the masked text and the keyboard up.

Where the failure comes from

The runner dispatches the tap first. The failure comes from a lookup that runs after it:

AGENT_DEVICE_RUNNER_SYNTHESIZED_DISPATCH kind=tap point=(201.0,406.0) reference=(0.0,0.0,402.0,874.0) orientation=1
    t =    12.52s Find the "Password" TextField
    t =    13.55s     Find the "Password" TextField (retry 1)
    t =    14.58s     Find the "Password" TextField (retry 2)
    t =    14.68s     Find: Descendants matching type TextField
    t =    14.68s     Find: Element at index 1
<unknown>:0: error: -[AgentDeviceRunnerUITests.RunnerTests testCommand] : Failed to get matching snapshot: No matches found for Element at index 1 from input {(
    TextField
)}
Possibly caused by runtime issues:
Automation type mismatch: computed TextField from legacy attributes vs Other from modern attribute. Input attributes and values: {
    "XC_kAXXCAttributeAutomationType" = 0;
    "XC_kAXXCAttributeElementBaseType" = UIAccessibilityElement;
    "XC_kAXXCAttributeElementType" = TextInputSemanticsObject;
    "XC_kAXXCAttributeTraits" = 146029150208;
}
AGENT_DEVICE_RUNNER_TARGET_CACHE_INVALIDATE reason=xctest_recorded_failure

Flutter's TextInputSemanticsObject reports TextField through the legacy attributes and Other (automation type 0) through the modern one. So a query by element type TextField finds nothing, and XCTest records a failure.

The request log for the same tap shows where the time goes:

phase duration
ios_runner_command_send (tap, including the three lookup retries) 2951 ms
ios_runner_session_invalidated, reason xctest_recorded_failure
runner restart (ios_runner_connect retries) 4046 ms
snapshot_capture for corroboration 4140 ms
ios_tap_failure_corroboration_identity_mismatch
request_failed XCTEST_RECORDED_FAILURE

Expected

A tap that was dispatched and landed should not fail the command. At minimum, it should not end the runner session.

We don't know the runner's internals, but two changes would each remove the cost here:

  • The post-dispatch lookup should not be able to record a test failure. For example, it could match by frame or identifier rather than by element type, or treat a miss as non-fatal.
  • Corroboration should accept the tap when the focused element changed to the tapped field. Here, corroboration seems to compare against an identity that includes this unstable type.

Workaround

When a tap fails with XCTEST_RECORDED_FAILURE ("while executing tap") right before we type, we type anyway and flag the tap as unconfirmed.

Related: #1599, #1605, #2273.

Dominant language
TypeScript
Stars
4.8k
Forks
315
Avg merge
11h 27m
Merged PRs (30d)
556

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from callstack/agent-device

All issues in callstack/agent-device

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.