Interactions briefly unresponsive after navigating between screens

[dkpalmer]

Our team has been doing some experimentation with useScreens in react-navigation. One thing I noticed was the time it takes for a screen to respond to touch events seems longer with react-native-screens enabled. Purely anecdotal, but trying to nav back and forth between screens pretty consistently takes 1 extra quick tap with useScreens compared to not using it.

Seeking feedback if this could be react-native-screens specific, the implementation in react-navigation, or possibly something in our own app.

[ferrannp]

I noticed the same on my Pixel 2.

[jack828]

@kmagiera Appreciate you're a busy person, but is there any chance of an update regarding a fix for this? Still an issue on latest, 2.0.0-alpha.25.

I would love to give it a go if you can point me in the right direction! :)

[kmagiera]

Hey all. I'm not really sure the details provided here are enough for me to look into. Please check the linked issues and in particular whether #188 fixes the problem.

I'd be happy to take a look or provide guidance but for that I'd need:

1. a minumum repro scenario
2. some video or instructions on how to reproduce it useing the provided code
3. confirmation whether Disable interactions on previous screen #188 fixes the problem (there are not enough details on Disable interactions on previous screen #188 apparently but we can work on improving the PR description if it fixes the problem)

[jack828]

Hey @kmagiera, you can find a demo app here https://github.com/jack828/RNScreenDemo.
I've written some setup instructions in the readme.

To demonstrate the issue:

First, comment out the line here.
Rapidly press the navigation button - you'll notice it responds immediately and without delay.
Then, add the line back in, and try again - you'll notice a significant delay before the button is "accepting" touch events again.

Unfortunately #188 does not help, as I've only seen this on android. (iOS untested)

Please let me know if this is enough information for you!

EDIT: I can't find the issue but someone mentioned this change in this file https://github.com/kmagiera/react-native-screens/blob/d4636d31302da01a12a711510ebad729d5d7558b/android/src/main/java/com/swmansion/rnscreens/Screen.java#L135

-   return mTransitioning ? PointerEvents.NONE : PointerEvents.AUTO;
+   return PointerEvents.AUTO;

Which, fixes the issue for screens that are not the "home" screen. Issue still occurs when trying to navigate from HomeScreen (see demo app)

EDIT 2: boooyahhh I found it #61 (comment)

[jack828]

Hey @kmagiera hope you're keeping well given the current circumstances!

Just wondering if you've had time to look into this?

[kmagiera]

Hey! Sorry, not yet, but I saw your repo and looks like it is something that would help investigate the issue. The comment about changing pointer events is helpful too and thank you for purchasing the solution, however the events checks where added there on purpose and I need to think a little bit more about what kind of consequences that change could have

[jack828]

No problem at all, I appreciate you have a lot to do already without this.
Please let me know if there is anything I can do to help!

[WoLewicki]

Closing this in favor of #624, where the logic of disabling interactions has been changed. Feel free to comment if something is wrong.

[bartzy]

@WoLewicki I don't think #624 resolved this.
I'm using the following versions:

react-native 0.63.4
react-native-screens 2.16.1
@react-navigation/native 5.8.10
@react-navigation/stack 5.12.8

I'm still getting the exact behavior as described in this issue - Interactions are not enabled briefly after animating to a screen.
Anything I'm doing wrong/not enabling?

[2snEM6]

#624 has not resolved the issue for me either. Anyone knows how to solve this? The library is amazing but having touch event delays bugs me

[WoLewicki]

You can check #775 and see if it is what you would like to have in your library. Please keep in mind that it introduces the ability to interact with screens that are transitioning.

[hirbod]

@WoLewicki which might be an issue for others. Should this be editable using a prop?

[WoLewicki]

@hirbod I thought about it, maybe it is a proper direction. cc @kmagiera.

[WoLewicki]

We came to the conclusion that we should not disable interaction during transition. If you want to have this controlled by the native side, you should use native-stack, which uses the interaction handling provided by the system. Therefore, we are merging #775. I will close this issue then. Please comment here if you have any questions or something is wrong.

[bartzy]

@WoLewicki I'm not sure I'm completely following.
By using native-stack, do you mean import { createNativeStackNavigator } from 'react-native-screens/native-stack'?
I get the interaction delay after a transition while using that import. Should I use something else?

[2snEM6]

@WoLewicki I'm not sure I'm completely following.

By using native-stack, do you mean import { createNativeStackNavigator } from 'react-native-screens/native-stack'?

I get the interaction delay after a transition while using that import. Should I use something else?

I confirm I get an interaction delay while using that import too

[WoLewicki]

If you want the user interaction controlled by the system, which means no interaction during transition just how in native iOS apps, you should use native-stack, just how @bartzy described it. When you apply #775, the stack navigator got by import { createStackNavigator } from 'react-navigation/stack' will not include disabling user interaction for the time of transition when providing enableScreens() anymore. Sorry if I didn't communicate it clearly enough. Also, could you specify if this problem was about iOS only? Or did it somehow happened on Android too?

[bartzy]

@WoLewicki By using import { createStackNavigator } from 'react-navigation/stack' and also calling enableScreens, are we even getting the native navigation behavior at all? I don't quite get what's the behavior with the regular createStackNavigator and enableScreens. I thought this library makes sense only with import { createNativeStackNavigator } from 'react-native-screens/native-stack'.

Also, the behavior with createNativeStackNavigator is not the same in iOS as regular native apps. With a regular native app, there is no delay at all for interacting with a new view controller that was just pushed to the navigation stack. With react-native-screens + createNativeStackNavigator (+ enableScreens obivously), there's a slight delay (probably 100-500ms?) where you can't tap on new elements after the transition ended. That is the issue that I think most people in this thread are reporting.

[2snEM6]

@WoLewicki By using import { createStackNavigator } from 'react-navigation/stack' and also calling enableScreens, are we even getting the native navigation behavior at all? I don't quite get what's the behavior with the regular createStackNavigator and enableScreens. I thought this library makes sense only with import { createNativeStackNavigator } from 'react-native-screens/native-stack'.

Also, the behavior with createNativeStackNavigator is not the same in iOS as regular native apps. With a regular native app, there is no delay at all for interacting with a new view controller that was just pushed to the navigation stack. With react-native-screens + createNativeStackNavigator (+ enableScreens obivously), there's a slight delay (probably 100-500ms?) where you can't tap on new elements after the transition ended. That is the issue that I think most people in this thread are reporting.

I use react-native-screens + createNativeStackNavigator + enable screens and I experience this delay too. This is especially noticeable when navigating back and for to a formSheet screen.

On native there is no delay whatsoever. I would love to help but have no idea where to start from. I wonder what the root cause of this delay is 🤔

[hirbod]

@bartzy this Library is not only for native-stack users but also for regular react navigation users who want benefits, native navigation containers and less memory consumption due to the view detaching when activating this library (eg enableScreens()).

The PR indeed fixes the interaction delay for users importing "stack" but not for us folks, using "native-stack". (Which rocks and always outperform the js stack)

Native stack still has a slight but pretty annoying touch rejection after a transition. If you open a form sheet and want to scroll inside of it or even when you close and want to use any pointer after it (menu, tab bar, scrolling) you will always end up "trying again", because the first touch is ignored when happened immediately. Reminds me of old CSS and focus bugs. The interaction delay is actually a pretty big UX issue and I doubt that this is anything system related or native. It feels like the system is kinda locked after a push:pop/dismiss for ~300-500ms

@WoLewicki maybe my explanations brings some light into the dark

[WoLewicki]

@hirbod so does it only happen in modals, or in all presentation kinds? Also, could you somehow show the difference in the time of the ability to click, scroll in the next/previous screen when native-stack compared to e.g. Settings app and App Store app (there is a modal there when you click your profile icon). I can spot the delay in those apps too, but probably I am missing something. Also, when providing stackAnimation: 'none', you can click the buttons immediately, which would suggest that there is no delay introduced by us. But here too, I might be missing something.

[hirbod]

@WoLewicki I can confirm everything you said. Same delay when using native Apps like "Settings" or the presentation modals inside the App Store. Exact same delay. No delay when I change screens using the tab-bar (material bottom bar) for example but also on default push/pop (which is also the same on my app). I tried different apps by Apple and they behave exactly the same.

So from what I can confirm in my "quick tests" is that native-screens indeed does not add some additional interaction delay on top of it.

So let's change the question: can we reduce that block time? I have no clue if there is an API for it, but if yes, could we make it configurable?

[bartzy]

@WoLewicki @hirbod
To me the delay is mainly noticeable in a Stack (UINavigationController) if I try to go back (swipe back) to the previous screen immediately after the transition "settled".
It feels like it's just ever-so-slightly not native that me and every user I showed this to has either commented about it or I noticed them swiping twice because of that.

[hirbod]

I noticed them swiping twice because of that.

@bartzy I also feel this. It feels like it occurs much more often in my React app than in other native apps.
For me its specially when I close a new presentation style modal.

@WoLewicki

Here are some videos. I filmed with a second phone so you can see my finger interactions.

Modal issues
https://streamable.com/snr3nt
-> If you wait like half a second; no issues. But if you want to start an interaction the moment the modal has left (but due to spring or any other background task visually but not technically finished), it will ignore the touch. Same for trying to interrupt the modal opening. You can't close it directly, you need to wait.

Tab bar
https://streamable.com/xo0nar
No issues with bottom tabs. You can switch and the screens react without interaction delay.

Push/Pop
https://streamable.com/y2t0rz
There are also delays with interaction, but not as bad as the modal, more natural and you really have "to force it" to miss it.

[bartzy]

@hirbod great videos, thanks!

@WoLewicki do you have any thoughts on this perhaps?

[WoLewicki]

@hirbod thanks very much for the videos! Can you add videos of using the same concepts in App Store and Settings apps on the phone? I really cannot spot the difference, but I get that it is rather a difficult problem and it would best to maybe somehow try and measure these times to see if they really differ.

[crystalarcus]

Push/Pop
https://streamable.com/y2t0rz
There are also delays with interaction, but not as bad as the modal, more natural and you really have "to force it" to miss it.

The link is not working, can you provide new links, or tell what they did in that video, I am experiencing a delay in response right after navigating to screen which is behind current screen, whenever I got back, and click again on search bar or navigation menu, ui dont responsed for 0.5 to 1.5 seconds ( my predictions ). I am using stack navigator inside a drawer navigator.