Detox icon indicating copy to clipboard operation
Detox copied to clipboard

.scrollTo() gets stuck on Android

Open Sonakshi997 opened this issue 4 years ago • 26 comments
trafficstars

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.

Screenshot 2021-05-20 at 6 16 12 PM

Steps To Reproduce

  1. detox test -c debug

Expected behavior

Should have scrolled the screen in either direction.

Detox Trace-Logs

Log_trace Log_trace_1 Log_trace_2

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 avatar May 21 '21 06:05 Sonakshi997

@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 avatar May 23 '21 10:05 d4vidi

@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() :

ConsoleLogsForScrollTo()

What happens on the terminal -

ConsoleLogs Output

This keeps on coming on the terminal and takes a lot of time to even end the test suite.

Thank you.

Sonakshi997 avatar May 26 '21 14:05 Sonakshi997

@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!

d4vidi avatar May 31 '21 08:05 d4vidi

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.

Sonakshi997 avatar Jun 02 '21 05:06 Sonakshi997

Apply the --record-logs all argument when running detox test. After the execution completes, you will have such files under an artifacts/ subdirectory.

d4vidi avatar Jun 02 '21 08:06 d4vidi

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.

process.log

Thanks.

Sonakshi997 avatar Jun 21 '21 06:06 Sonakshi997

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.

Sonakshi997 avatar Jul 08 '21 04:07 Sonakshi997

Yikes. There shouldn't be such hacks in Detox. @jonathanmos could we get to the bottom of this together?

d4vidi avatar Jul 19 '21 20:07 d4vidi

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.

stale[bot] avatar Aug 18 '21 23:08 stale[bot]

The issue has been closed for inactivity.

stale[bot] avatar Aug 26 '21 01:08 stale[bot]

@jonathanmos were you able to make any progress here?

d4vidi avatar Aug 29 '21 12:08 d4vidi

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.

stale[bot] avatar Sep 28 '21 20:09 stale[bot]

@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?

jonathanmos avatar Oct 04 '21 11:10 jonathanmos

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.

no-response[bot] avatar Oct 11 '21 12:10 no-response[bot]

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":[]}}]}```

AdamTyler avatar Nov 08 '21 23:11 AdamTyler

@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.

Sonakshi997 avatar Nov 10 '21 16:11 Sonakshi997

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.

stale[bot] avatar Dec 11 '21 04:12 stale[bot]

The issue has been closed for inactivity.

stale[bot] avatar Dec 18 '21 04:12 stale[bot]

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>

jonathanmos avatar Jan 04 '22 09:01 jonathanmos

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.

stale[bot] avatar Feb 05 '22 02:02 stale[bot]

The issue has been closed for inactivity.

stale[bot] avatar Feb 12 '22 06:02 stale[bot]

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.

stale[bot] avatar Mar 16 '22 01:03 stale[bot]

The issue has been closed for inactivity.

stale[bot] avatar Mar 23 '22 14:03 stale[bot]

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.

stale[bot] avatar Jun 18 '22 16:06 stale[bot]

@jonathanmos any action items here?

d4vidi avatar Jun 19 '22 08:06 d4vidi

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.

stale[bot] avatar Jul 25 '22 06:07 stale[bot]

We have hit the same problem as described originally, so it seems that this is not fixed.

Mellbourn avatar Jan 23 '23 15:01 Mellbourn

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.

twocs avatar Apr 04 '23 04:04 twocs

Also had to set style={{flex: 1}} on a Flatlist's parent, which was a Native-Base HStack.

twocs avatar Apr 26 '23 05:04 twocs

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.

owens-ben avatar Sep 07 '23 18:09 owens-ben