New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Touch events do not work when multiple screens are active on Android #61
Comments
+1 We recently upgraded to React Navigation 3.X and it looks like all 3.X compatible versions of react-native-screens have this issue. We use transparentCard for our dialog system as well. |
@janicduplessis @jbacon-zynga |
Think I'm seeing a similar issue on iOS: when navigating back to a previous screen in a stack that has transparentCard set, the screen doesn't respond to touch events. Had a poke around with the Element Inspector and it seems that the component tree is "StackViewLayout > ScreenContainer" after navigating back, compared to "StackViewLayout > SceneView > [ Screen ]" initially. Navigation gestures still work, screen focus events still trigger and navigating from the screen via code is fine. Will investigate further and try to get a snack up and running asap |
@GfxKai I'm running into the same issue exactly, yet I haven't been able to replicate it in a snack. I can confirm that the component tree ends in |
Yeah I couldn't reproduce in a snack either. Not sure why I think the issue is that whenever a screen is added to a stack, the block here loops through all screens that are already mounted and active (usually only the screen immediately below the one being added to the top of the stack) and disables user interaction for the duration of the transition. This block checks for the end of the transition whenever a screen is added or removed (by waiting for there to only be 1 active screen) and then re-enables user interaction on the top-most screen. Since (I think) the transparentCard prop keeps all screens in the stack active, once you add a third screen to a transparent stack, user interaction for the two screens underneath is disabled and never re-enabled again. Hence, when you pop that third screen, you are left with an unresponsive screen underneath. Unfortunately I really don't know enough Obj-C to come up with a solution other than just allowing user interaction during transition 😬 I imagine we need some other way of detecting a finished transition other than checking the number of active screens. Perhaps it's possible to watch for a transition finish using onDidFocus on the js side then set a prop on the UIView over the bridge? 🤷♂️ |
react-native-screens disable touch interaction for the duration of screen transition (so that you can't interact with buttons on the screen that is going away). The way we detect screen transition now is when there are two or more active screens. I believe that is the case when you have a transaprent dialog too. This would need to be changed in screen implementation (both on Android and iOS) |
Is this change possible in react-native-screens or it needs to be done in the respective OSes? |
if somebody wants a quick repo to see this I added it here : #79 |
@ovy9086 - let's keep this all within this thread as it's the same underlying issue. @ovy9086's other post below
|
@kmagiera What was the reason for moving touch event handling inside rn-screens vs using the pointerEvents from JS that react-navigation sets like it was before? |
This seems contradictory to the documentation:
|
I found this commit caused a similar problem in the FluidTransitions package. Since that change was introduced in alpha-18, I use alpha-17 to work around the problem. |
still no updates on this ? :) |
I'm using: |
I have this same issue, remove of useScreens(); fixed this problem |
I'm using the same workaround as @marcinj1, but it makes me sad, of course. 😔 |
I'm also facing this issue. ConfigurationExpo SDK 32 To reproduce:
ResolutionRemove |
Same issue. Weird expo would include such an unstable library. I’d say this issue will only become more common with people trying to improve performance. Removing react-native-screens until a fix is added. So sad though. |
This seems super-buggy atm. On Android, initially this seems to work, but as soon as you start swiping and then release, no gestures such as touch work after that. Same issue can also be reproduced if you just leave all screens active. Seems to be software-mansion/react-native-screens#61 On iOS, I get `undefined is not an object (evaluating 'this._ref.setNativeProps')`. The `ref` is undefined for some reason only on iOS: https://github.com/kmagiera/react-native-screens/blob/acf80e640c584bf4019cfaf9356ee44b09e7dc99/src/screens.native.js#L44 If you do `active={focused ? 1 : 0}`, it works as expected on Android (though not desirable). However, on iOS, no gestures such as touch seem to work.
This seems super-buggy atm. On Android, initially this seems to work, but as soon as you start swiping and then release, no gestures such as touch work after that. Same issue can also be reproduced if you just leave all screens active. Seems to be software-mansion/react-native-screens#61 On iOS, I get `undefined is not an object (evaluating 'this._ref.setNativeProps')`. The `ref` is undefined for some reason only on iOS: https://github.com/kmagiera/react-native-screens/blob/acf80e640c584bf4019cfaf9356ee44b09e7dc99/src/screens.native.js#L44 If you do `active={focused ? 1 : 0}`, it works as expected on Android (though not desirable). However, on iOS, no gestures such as touch seem to work.
This seems super-buggy atm. On Android, initially this seems to work, but as soon as you start swiping and then release, no gestures such as touch work after that. Same issue can also be reproduced if you just leave all screens active. Seems to be software-mansion/react-native-screens#61 On iOS, I get `undefined is not an object (evaluating 'this._ref.setNativeProps')`. The `ref` is undefined for some reason only on iOS: https://github.com/kmagiera/react-native-screens/blob/acf80e640c584bf4019cfaf9356ee44b09e7dc99/src/screens.native.js#L44 If you do `active={focused ? 1 : 0}`, it works as expected on Android (though not desirable). However, on iOS, no gestures such as touch seem to work.
This seems super-buggy atm. On Android, initially this seems to work, but as soon as you start swiping and then release, no gestures such as touch work after that. Same issue can also be reproduced if you just leave all screens active. Seems to be software-mansion/react-native-screens#61 On iOS, I get `undefined is not an object (evaluating 'this._ref.setNativeProps')`. The `ref` is undefined for some reason only on iOS: https://github.com/kmagiera/react-native-screens/blob/acf80e640c584bf4019cfaf9356ee44b09e7dc99/src/screens.native.js#L44 If you do `active={focused ? 1 : 0}`, it works as expected on Android (though not desirable). However, on iOS, no gestures such as touch seem to work.
Same here ... :( |
Facing the same problem here. Will this be fixed with SDK 33? |
Same problem here, removing react-native-screens solved the problem. |
After upgrading to Expo 33, my original issue no longer occurred on iOS. I did however have a problem with nested ScrollViews/FlatLists—I could scroll them, but the list items were not tappable. I resolved that by adding I'm still facing issues on Android TouchableOpacity components are not responding to touch in any nested screens on Android when using |
I did a little expirement and changed this line from @Override
public PointerEvents getPointerEvents() {
return mTransitioning ? PointerEvents.NONE : PointerEvents.AUTO;
} to : @Override
public PointerEvents getPointerEvents() {
return PointerEvents.AUTO;
} This seems to resolve the issue as all the views will be able to receive touch events even when "transitioning" and I haven't seen any side effects when it comes to performance. I might make a PR with a config to override the default behaviour of this method... |
any news on this one? shouldn't this kind of stuff handled in navigation itself? using |
I just wanted to mention this one more time, I think this kind of stuff should be implemented in navigation level (probably in js), it doesn't feel any good to have debouncing only with |
Same issue here useScreens() + transparentCard: true. |
Anyone had the chance to look into if there is a similar solution in iOS for @emeraldsanto's changes? |
I change the import of the StackNavigator from |
@alexpareto I can look into it but according to my testing the events are still triggered on iOS without changing anything. I found the piece of code managing the touch events in
It seems to be pretty much the same code as Android, the difference is most likel in the calculation of active screens. I can check it out and report back here if I find anything. |
@15matias15's solution (to use the in-package |
@emeraldsanto's solution worked on Android For iOS, I fixed it by disabling the logic which disables interactions during a transition. I did this by going to RNSScreenContainer.m and changed
to
|
Still looking for a solution that works on Android... |
Any update on this? This is happening to me as well on iOS while using |
This doesn't seem to be an issue for me anymore after upgrading to the following versions:
Hope that can help |
I had same issue, reinstalling the |
I'm running into this issue with RN Screens v3. I'm building a pager with RN Screens but once I want to have more than one page active at the same time, touches are not available anymore. |
Only one |
Thanks @WoLewicki, my use case is a large list where I would like to offload the parts of the list that are not visible. |
I am afraid it is not the use case, at least not for now. |
I added a way to have transparent scenes in react-navigation a while back to support dialogs (https://github.com/react-navigation/react-navigation-stack/blob/master/src/views/StackView/StackViewCard.js#L35). It keeps all screens active in the stack but this seems to break touch events on Android because of the logic here: https://github.com/kmagiera/react-native-screens/blob/master/android/src/main/java/com/swmansion/rnscreens/ScreenContainer.java#L189
The react-navigation code is basically this:
The text was updated successfully, but these errors were encountered: