Detox
Detox copied to clipboard
.scrollTo() gets stuck on Android
Describe the bug
I've been using detox from last few months and this issue came into my observation. On the simulator I cannot see any motion of the scroller. I do not understand any reason for it to not work properly. Can it be the detox version issue? The scroller was earlier working in all the test files so far till past 2 weeks and now failing in few of the files.
The testing screen halts when .scrollTo('top') action statement arises and nothing happens afterwards. If anyone have any solution to this, please share. It would be of great help.

Steps To Reproduce
- detox test -c debug
Expected behavior
Should have scrolled the screen in either direction.
Detox Trace-Logs

Full log trace -> test_log_trace.pdf
Environment :
- Detox: 18.7.0
- React Native: 0.63.3
- Node: 14.16.0
- Device: Pixel_API_23x86
- OS: macOS Big Sur 11.2.3
- Test-runner: jest-circus
@Sonakshi997 it's really hard to tell what wrong this way. Could you please use the --take-screenshots all, --record-video all and --record-logs all arguments to detox test and provide the artifacts generated under the artifacts/ folder?
Also, before doing so, please also add logs before, after and in between the scrollTo() calls, using console.log.
Thanks.
@d4vidi I understand. Here is what you asked for. I hope the issue gets clear now as I am facing this on various different screens now. Also, the ScrollTo() works perfectly fine on IOS.
What is expected from the ScrollTo() -> Done manually:
https://user-images.githubusercontent.com/79457969/119674108-8f459180-be59-11eb-9f3a-ba79c8cec8dd.mov
What Detox is doing via test:
https://user-images.githubusercontent.com/79457969/119674203-a4222500-be59-11eb-91c7-2bc821a223b7.mov
Console Logs Before and After the ScrollTo() :

What happens on the terminal -

This keeps on coming on the terminal and takes a lot of time to even end the test suite.
Thank you.
@Sonakshi997 this is great, thank you. Please also spot a file called process.log under the failing test and upload it as well. Thank you!
I understand @d4vidi . I tried finding this file, but could not. Can you describe in detail where can I find this file. That will help a lot.
Apply the --record-logs all argument when running detox test. After the execution completes, you will have such files under an artifacts/ subdirectory.
Hi @d4vidi . Here is the process.log file you requested. Let me know if anything else is required from my side. I can see this scrollTo() issue in various more files. I hope it gets resolved soon.
Thanks.
Hi @d4vidi . I was able to overcome this stuck .scrollTo() problem by doing this.
I created a function that takes the testID as arguments and calls it in files where my scrollTo() does not work.
await element(by.id(scroller_testID)).scroll(scrollValue, 'down')
await element(by.id(scroller_testID)).tapAtPoint({
x: 10,
y: 10,
})
await element(by.id(screenView_testID)).tapAtPoint({
x: 10,
y: 20,
})
I believe this is just a temporary solution or a hack to make things work for now. Let me know if there is any progress at your part. Thank you.
Yikes. There shouldn't be such hacks in Detox. @jonathanmos could we get to the bottom of this together?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe the issue is still relevant, please test on the latest Detox and report back.
Thank you for your contributions!
For more information on bots in this reporsitory, read this discussion.
The issue has been closed for inactivity.
@jonathanmos were you able to make any progress here?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe the issue is still relevant, please test on the latest Detox and report back.
Thank you for your contributions!
For more information on bots in this reporsitory, read this discussion.
@Sonakshi997 I was not able to reproduce this issue, except when the soft keyboard was open due to typing in the textfield - in which case, I added tapReturnKey to dismiss it and the test subsequently passed properly. What is the purpose of tapAtPoint? Is it to dismiss the keyboard or for another reason?
This issue has been automatically closed because there has been no response to our request for more information from the original author.
For more information on bots in this reporsitory, read this discussion.
I'm seeing this exact issue. Works fine on iOS but Android hangs until timing out on scrollTo actions:
detox[15977] INFO: [APP_STATUS] App synchronization debug: The app appears to be idle!
detox[15977] INFO: [APP_STATUS] App synchronization debug: The app appears to be idle!
detox[15977] INFO: [APP_STATUS] App synchronization debug: The app appears to be idle!
detox[15977] INFO: [APP_STATUS] App synchronization debug: The app appears to be idle!
detox[15977] INFO: [APP_STATUS] App synchronization debug: The app appears to be idle!
detox[15977] INFO: [APP_STATUS] App synchronization debug: The app appears to be idle!
detox[15977] INFO: [APP_STATUS] App synchronization debug: The app appears to be idle!
detox[15977] INFO: [APP_STATUS] App synchronization debug: The app appears to be idle!
detox[15977] INFO: [APP_STATUS] App synchronization debug: The app appears to be idle!
detox[15977] INFO: [APP_STATUS] App synchronization debug: The app appears to be idle!
detox[15977] INFO: [APP_STATUS] App synchronization debug: The app appears to be idle!
detox[15977] INFO: [APP_STATUS] App synchronization debug: The app appears to be idle!
detox[15977] WARN: [PENDING_REQUESTS] The app has not responded to the network requests below:
(id = 50) invoke: {"target":{"type":"Class","value":"com.wix.detox.espresso.EspressoDetox"},"method":"perform","args":[{"type":"Invocation","value":{"target":{"type":"Class","value":"androidx.test.espresso.Espresso"},"method":"onView","args":[{"type":"Invocation","value":{"target":{"type":"Class","value":"com.wix.detox.espresso.DetoxMatcher"},"method":"matcherForTestId","args":["create-event-preview-post"]}}]}},{"type":"Invocation","value":{"target":{"type":"Class","value":"com.wix.detox.espresso.DetoxViewActions"},"method":"click","args":[]}}]}```
@Sonakshi997 I was not able to reproduce this issue, except when the soft keyboard was open due to typing in the textfield - in which case, I added tapReturnKey to dismiss it and the test subsequently passed properly. What is the purpose of tapAtPoint? Is it to dismiss the keyboard or for another reason?
Yes, after typing on an input field, to dismiss the keyboard I used tapAtPoint(which works fine). But here the issue comes after when I think, on applying scollTo('direction') it should go in either direction, but rather the screen stays still. The console shows me initially it is busy with threads and then app is idle comes 'n' number of times and on the UI nothing happens. Just still. No particular reason I could find too for the screen stuck as there was no interruption at the screen as well.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe the issue is still relevant, please test on the latest Detox and report back.
Thank you for your contributions!
For more information on bots in this reporsitory, read this discussion.
The issue has been closed for inactivity.
I was able to reproduce the issue, which looks like it occurs with any view placed before a scrollview. Although I haven't found the root cause yet, I did find that adding style={{flex: 1}} to the parent view seems to fix the problem (as a workaround) - e.g.:
<View testID={'screenView_id'} style={{flex: 1}}>
<TextInput testID={'textInput_id'} placeholder={'Type here'}/>
<ScrollView testID={'scrollView_id'}>
...
</ScrollView>
</View>
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe the issue is still relevant, please test on the latest Detox and report back.
Thank you for your contributions!
For more information on bots in this reporsitory, read this discussion.
The issue has been closed for inactivity.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe the issue is still relevant, please test on the latest Detox and report back.
Thank you for your contributions!
For more information on bots in this reporsitory, read this discussion.
The issue has been closed for inactivity.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe the issue is still relevant, please test on the latest Detox and report back.
Thank you for your contributions!
For more information on bots in this reporsitory, read this discussion.
@jonathanmos any action items here?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe the issue is still relevant, please test on the latest Detox and report back.
Thank you for your contributions!
For more information on bots in this reporsitory, read this discussion.
We have hit the same problem as described originally, so it seems that this is not fixed.
Still seeing this problem. The ScrollView is inside a SafeAreaView, but ScrollTo just displays "App synchronization debug: The app appears to be idle!"
Finally setting <SafeAreaView style={{flex: 1}}> and it works.
Also had to set style={{flex: 1}} on a Flatlist's parent, which was a Native-Base HStack.
This is STILL not fixed.
I cannot understand the logic of closing issues for inactivity, when the developers are the ones who are the ones who are inactive. This makes Detox essentially worthless for Android development. Is that not a priority? Serious question.