iOS: tapping a Flutter password field records an XCTest failure and restarts the runner, although the tap lands
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
- Domain
- mobile-dev, testing-qa
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-device0.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
TextFieldand a passwordTextFieldwithobscureText: 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
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from callstack/agent-device
-
Difficulty 1/5 Under an hour Newbie friendliness 82/100
callstack/agent-device#3062 ·
Maintainers usually reply within 1 day
-
ready-for-agent
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
callstack/agent-device#2995 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
callstack/agent-device#1869 ·
Maintainers usually reply within 1 day
-
needs-triage
Difficulty 4/5 3-5 days Newbie friendliness 38/100
callstack/agent-device#3077 ·
Maintainers usually reply within 1 day
-
needs-triage
Difficulty 4/5 3-5 days Newbie friendliness 68/100
callstack/agent-device#3076 ·
Maintainers usually reply within 1 day
All issues in callstack/agent-device
Similar issues
-
area/frontend good first issue kind/cooldown
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
voidzero-dev/oxc-angular-compiler#511 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
langchain-ai/deepagentsjs#898 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 92/100
anomalyco/models.dev#8509 · 2 comments ·
Maintainers usually reply within 1 day
-
bug documentation P2 UI/UX
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day