fill repairs and fails on fields that normalize their input
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 76/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- swift, typescript
Research direction
Start in apple/runner/AgentDeviceRunner/AgentDeviceRunnerUITests/RunnerTests+TextTyping.swift, especially textEntryValueMatchesExpected and isRepairableTextEntryMismatch, then inspect the examples/test-app FormScreen field-phone fixture. Verify the current fill path and runner logs before changing behavior. Done means normalized input passes without clear/retype, while genuinely dropped characters still mismatch and repair.
Written by the indexing model from the issue text.
Description
Summary
fill verifies text entry by exact string comparison against element.value. Any field that normalizes what it stores — digit grouping, masks, currency formatting — fails that comparison even when entry succeeded. fill then runs its destructive repair (clear + retype) against an already-correct field, and finally returns TEXT_ENTRY_MISMATCH.
Observed
iOS 26.6.1, physical iPhone SE (3rd generation), agent-device 0.20.5. The relevant logic is unchanged on main. Target: a Flutter text field applying a ## ### ## ## digit-grouping formatter.
$ agent-device fill 187 286 '000629177'
Error (TEXT_ENTRY_MISMATCH): text entry verification failed:
expected "000629177", observed "00 062 91 77"
00 062 91 77 is exactly the requested digits, formatted. The field held the correct value both before and after the repair. From the runner log, emitted before repair ran:
AGENT_DEVICE_RUNNER_REPAIR_TEXT_ENTRY expectedLength=9 observedLength=12
observedLength=12 is the complete, correctly formatted value.
Entry itself is not the problem. agent-device type '000629188' --delay-ms 0 into the same empty field produces the correct value on the first attempt, so there is no dropped-character or timing issue to repair.
Cause
In apple/runner/AgentDeviceRunner/AgentDeviceRunnerUITests/RunnerTests+TextTyping.swift on main:
textEntryValueMatchesExpected(~line 510) accepts only exact equality, plus an exception for a trailing submit suffix. Any normalization fails.isRepairableTextEntryMismatch(~line 601) returnstrueunconditionally whenrepairMode == .replacement, so it never consultsisLikelyDroppedCharacterTextEntryMismatchimmediately below it. That subsequence check would already classify this mismatch as non-repairable.
So replacement-mode entry into any normalizing field always follows the same path: mismatch, repair, mismatch, error.
Impact
The repair is the more serious half. clearTextInput sends moveCaretToEnd — an edge tap computed from a frame the code's own comment notes may be stale — plus up to 120 delete keystrokes, then retypes. It mutates a field that was already correct, and the retype has no first-character warmup, so it is strictly less reliable than the entry it replaces.
There is no way to opt out. verified == false is a hard error in RunnerTests+CommandExecution.swift, and fill exposes no --no-verify or --expect flag.
Required behavior
fillsucceeds when the field's value is a normalization of the requested text — at minimum, when every requested character appears in order in the observed value.- Replacement-mode repair does not run when the observed value already contains the requested characters in order.
- Optionally, a way to state the expected post-normalization value:
agent-device fill <target> '000629177' --expect '00 062 91 77'
Completion conditions
fillinto a field that groups digits as they are typed returns ok and performs no clear/retype.- A field that genuinely drops characters still mismatches and still repairs.
- Regression fixture:
examples/test-app's FormScreen already has afield-phoneinput, which currently stores the raw value. Formatting it on change reproduces this, andfill 'id=field-phone' '000629177'should then pass.
Related
typecannot verify on iOS at all.focusedTextInputreturns nil by design there, so baretyperesolves no target element,expectedTextcomes out nil, andverifyTextEntryreturnsverified: nil. This makestypeappear more reliable thanfillwhen it is only unchecked. Probably worth tracking separately.- #2578 / #2592 concern a different Flutter symptom (focus acquisition, not verification).
- Dominant language
- TypeScript
- Stars
- 4.7k
- Forks
- 304
- Avg merge
- 11h 46m
- Merged PRs (30d)
- 471
Contributor 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
-
mutation-model: indirect-ownership self-test pins a test that stopped reaching scroll-edge-state Openbug needs-triage
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
callstack/agent-device#2547 ·
-
refactor
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
callstack/agent-device#2530 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
callstack/agent-device#1869 ·
-
needs-triage
Difficulty 4/5 3-5 days Newbie friendliness 55/100
callstack/agent-device#2714 ·
-
iOS smoke fails in verify-installed-snapshot-bridge when a cold xcrun probe eats the shared deadline Openneeds-triage
Difficulty 4/5 3-5 days Newbie friendliness 48/100
callstack/agent-device#2712 ·
All issues in callstack/agent-device
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
0xMiden/bridge-portal#132 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
area:tools bug good first issue help wanted priority:P2
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
TaewoooPark/Motifcode#14 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
newrelic-experimental/preflight#793 · 1 comment ·