Repository navigation
fix(maestro): type inputText with a 75 ms per-character delay on Android - #3725
Conversation
Maestro 2.5.1 types inputText one character at a time with a 75 ms sleep. The daemon port sent `type` with no delay, so Android's IME path committed the whole string at once and debounced handlers fired once. Own the delay in the Maestro compatibility policy and pass it from the runtime port on Android only. iOS is unchanged. Fixes callstack#2159
|
Live check on a Pixel_7_API_36 emulator (branch build, 4331a7f): replay --maestro I haven't run the debounced Catalog search field from the test app. Its debounce is 320 ms (examples/test-app/src/lab-state.tsx), longer than the ~120 ms per-character gap, so it fires once at the end with or without this change. The final results would look the same either way. If you want a check that tells the two apart, the test app could expose a draft-change counter next to the search field, and a flow could assert it. That would be a separate change to the test app. Happy to do it here or as a follow-up, whichever you prefer. Appium/Limrun backends aren't covered; I only checked the ADB path. |
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
All reported issues were addressed across 7 files
Reply to a comment to ask cubic a question or push back. It learns from your replies.
View guided diff | Re-trigger cubic
|
Screen recordings: Maestro
With the PR the text arrives one character at a time, and Settings updates its results while typing. On the released build the whole string lands at once. API 34 wasn't run because its system image isn't installed on this machine. The first API 32 run hit a 10 s adb timeout on a fresh emulator and passed on the retry. Videos, in table order: Pixel_7_API_36-released-0.20.3.mp4Pixel_7_API_36.mp4ad2159_API_32-released-0.20.3.mp4ad2159_API_32.mp4 |
eraseText sends its backspaces through the same type helper as inputText, so it inherited the 75 ms per-character delay and a default 50-character erase gained about 3.75 s. Pass the delay only from the inputText path.
|
This PR is ready at 327c9e2. The 75 ms Android inputText pacing is limited to inputText, and eraseText keeps its old path with no delay on both platforms. CI is green, and I did not run the tests locally. Not blocking: the pacing test declares its own 75 value instead of reading the shipped preset (https://github.com/callstack/agent-device/blob/327c9e2/packages/maestro/src/daemon-port/__tests__/daemon-runtime-port-input-text-pacing.test.ts#L46), so the number is spelled in three places, and Android inputText now takes about 0.12 s per character, which the Maestro docs page does not mention (https://github.com/callstack/agent-device/blob/327c9e2/website/docs/docs/run-maestro-flows.md#L29). You can take or leave both. The cubic-dev-ai thread about eraseText inheriting the delay no longer applies, because eraseText calls the shared helper without a delay at this head and the test.each asserts that on both platforms. Please resolve it: #3725 (comment) Two things I could not check: the 75 ms value against the pinned 2.5.1 bytecode, and whether the Appium and Limrun providers honor the delay they now receive. A live run on a field that debounces under 75 ms, or with a draft-change counter, would show the per-keystroke onChange from #2159. That run is not required to merge. |
thymikee
added
the
ready-for-human
|
Thanks! In 6474ef9 I added a Typing boundary to the versioned Maestro help ( I kept the test's own
|
2 participants
Summary
Maestro
inputTexton Android now types with Maestro 2.5.1's 75 ms per-character delay (MaestroDriverService.kt), so debounced inputs see a change per keystroke instead of one batched commit. iOS is unchanged. The default lives in the Maestro compatibility policy next to the other 2.5.1 defaults and reaches the port throughMAESTRO_RUNTIME_ADAPTER_POLICY. No new CLI flag or flow grammar. 7 files touched, no scope expansion.Fixes #2159
Validation
pnpm check:affected --runon an identical working tree, not--head, so the receipt is not commit-exact): format, lint, typecheck, layering, fallow, build and vitest-related all pass.inputTextsendsdelayMs: 75, iOSinputTextsends none, anderaseTextsends none on either platform. The Android assertions failed before each change.delayMs: 0; they show 75 reaching the provider seam.eraseTextfix in 327c9e2, which doesn't touch theinputTextpath):replay --maestroinputTextof 100 chars into Settings search took 12,023 ms on API 36 and 15,602 ms on API 32; released 0.20.3 took 375 ms and 299 ms. Recordings are in the comments.