inputText is typing too fast and skipping characters when app stutters/jank
When running with Android emulator and calling inputText, it appears that the app suffers some stutter or jank and the command misses some characters. For example:
When executing inputText to type Lorem ipsum, sometimes it'll actually type Loemipsu. The skipped characters are random, so it does not appear to be a keyboard auto-correction. Sometimes, the same test will type characters correctly and tests will succeed.
I've tested that on debug builds, which are not optimized and the app can suffer from stutters or jank, and the problem is more frequent, but the same also works with an optimized release build.
My (hopefully) temporary workaround for this is to have one command per character, like this:
- inputText: "l"
- inputText: "o"
- inputText: "r"
- inputText: "e"
- inputText: "m"
Is there any way to set typing or command speed? If not, this could be a possible implementation for cases like this. E2E should have some breathing space when typing to avoid errors like this.
@edgarlealbd is your problem maybe happening inside an Android webview, like some webform or login screen inside the app?
Is it a clear native app, or some sort of prebuilt via React Native?
@pwicherski the typing in question is not happening inside a WebView. The app is built with Flutter.
Update: I can't reproduce the error locally with an Android 10 emulator, only with an Android 12 (API 31).
We've opened up a fix for this. The fix should be included in the next release of Maestro once this is landed #417
Hey @edgarlealbd @pwicherski
I have just merged the fix can you upgrade the local maestro to head and try these commands to check if this is fixed. Would recommend to do it multiple times as this was inconsistent. To upgrade:
brew uninstall maestro
brew install maestro-head --HEAD
Let me know if this works will release this in the new version
To go back on stable after checking
brew uninstall maestro-head
brew install maestro
@amanjeetsingh150 I'm getting java-related errors when running with the head version from homebrew:
I have a Mac Pro M1 Max.
Exception in thread "main" java.lang.UnsupportedClassVersionError: maestro_android/MaestroDriverGrpc has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:756)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
at maestro.drivers.AndroidDriver.<init>(AndroidDriver.kt:65)
at maestro.Maestro$Companion.android(Maestro.kt:402)
at maestro.Maestro$Companion.android$default(Maestro.kt:401)
at maestro.cli.util.MaestroFactory.createMaestro(MaestroFactory.kt:40)
at maestro.cli.command.TestCommand.call(TestCommand.kt:74)
at maestro.cli.command.TestCommand.call(TestCommand.kt:36)
at picocli.CommandLine.executeUserObject(CommandLine.java:1933)
at picocli.CommandLine.access$1200(CommandLine.java:145)
at picocli.CommandLine$RunLast.executeUserObjectOfLastSubcommandWithSameParent(CommandLine.java:2332)
at picocli.CommandLine$RunLast.handle(CommandLine.java:2326)
at picocli.CommandLine$RunLast.handle(CommandLine.java:2291)
at picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:2159)
at picocli.CommandLine.execute(CommandLine.java:2058)
at maestro.cli.AppKt.main(App.kt:109)
Hey @edgarlealbd , have created fix for this can you try with latest head again by:
brew uninstall maestro-head
brew install maestro-head --HEAD
Let me know if this seems consistent now.
Hey @edgarlealbd can you confirm that the latest version works fine for you?
@amanjeetsingh150 I thought that I already commented this out. It's is working fine now.
Awesome @edgarfroes thanks 🙌
Hey @amanjeetsingh150 - this, or similar is still happening - installed Maestro today - using RN, pretty small app right now
Video below - let me know if you need anymore details?
https://user-images.githubusercontent.com/13877025/215972194-a7ba6890-ea3a-4944-8341-ccec9fea8ff4.mp4
Hey, @janyk @artem888 is working on a fix here. Should be fixed by this: https://github.com/mobile-dev-inc/maestro/pull/720. Can you open a separate issue though for this it will be easy to follow up.
@amanjeetsingh150 FYI, this is still happening on iOS. I have the latest Maestro CLI installed. The app is react native, running in debug mode (so, quite slow)
Workaround:
Create sub-flow myInput.yaml:
appId: com.myapp
env:
TEXT: ${TEXT}
ATTEMPTS_LIMIT: ${ATTEMPTS_LIMIT || 5}
---
- evalScript: ${output.status = 'unknown'}
- evalScript: ${output.attempt = 1}
- repeat:
while:
true: ${output.status === 'unknown'}
commands:
- inputText: "${TEXT}" # Fill text field
- runFlow:
when:
visible: "${TEXT}" # check if entered text is correct
commands:
- evalScript: ${output.status = 'success'}
- runFlow:
when:
true: ${output.status != 'success'}
commands:
- eraseText # Clear text field
- evalScript: ${output.attempt = output.attempt + 1}
- runFlow:
when:
true: ${output.attempt >= ATTEMPTS_LIMIT}
commands:
- evalScript: ${output.status = 'timeout'}
And then use that sub-flow instead of inputText:
- runFlow:
file: myInput.yaml
env:
TEXT: "My text"
ATTEMPTS_LIMIT: 3 # optional (by default 5)
I'm facing the same issue in version 1.26.1 And I have this behaviour not only for - inputText: command, but for - 'inputRandomEmail' command too.
- 'inputRandomEmail' command typing invalid emails sometimes and I think because of the same reason as inputText: I don't know if this is possible, but visually it looks like the print in the input is filling in two places, as if there are two cursors in the input.
instead of [email protected] I got [email protected] Upgraded to 1.27.0 - issue still here
I am seeing a slightly different, but potentially related issue. I have the following flow:
appId: my-app
---
- tapOn: "Username"
- inputText: "Ethan"
- tapOn: "Password"
- inputText: "blklbl"
- tapOn: "Sign In"
- assertVisible: .*Current Duty Status.*
What I am seeing is that the flow usually works without issue. However, every so often (on ~20% of runs or somewhere in that ballpark) an extra "y" will be added at the end of the password, causing the test to fail (since it becomes the wrong password with a "y" at the end). It is always a "y" character for some reason. I can open a separate issue if that makes sense, but thought it might be related to this existing issue.
@lossen @el-ethan does this happen on Android or on iOS? If this is an issue on iOS, please file a new bug report with as much details as possible and we'll take it from there to reduce noise in this issue.
for me is only happens on iOS
Typing a couple of characters at a time seems to work well:
- tapOn: 'Email address'
- inputText: 'si'
- inputText: 'mon'
- inputText: '+'
- inputText: 'em'
- inputText: 'ail'
- inputText: '@'
- inputText: 'coo'
- inputText: 'kin'
- inputText: '.com'
instead of
- tapOn: 'Email address'
- inputText: '[email protected]'
Looking forward to seeing this PR merged though 🤞
Any news on this?
It's still happening with version 1.30.4
+1
hey folks! we applied one more fix, which hopefully should fix majority of the issues with inputText. it's going to be released in the next maestro cli version
sweet! that's exciting, thanks for working on this issue. is there a planned release date for that version?
sweet! that's exciting, thanks for working on this issue. is there a planned release date for that version?
we're planning to release it early next week
sounds good. by any chance is this fix to inputText going to also touch eraseText? That one seems to be pretty buggy in maestro cloud as well, but maybe it's a related issue.
@ferdy-roz not really, since eraseText is a separate command. but might be flaky for similar reasons, going to check that
Looks like inputText might be fixed, but yes eraseText still has issue in Maestro Cloud
@ferdy-roz that's good to hear, I'll try to fix eraseText in the next version. can you please provide me with uploadId or appId for the failing maestro cloud upload?
@artem888 where do I find that in the cloud console?
