Bug with permissions dialog and position

[ahce]

Description

• Position bug: The drawer is behind the button:
  
• Position fix: Set zIndex
  
• Permission dialog bug: The drawer in close mode is visible behind the dialog, this occur in special situations
  • Form 1:
    • First: press next up to value 2
    • Second: focus the textinput and open keyboard
    • Third: press next again
  • Form 2:
    • First: press next or back button repeatedly

Steps

Result

Note

This bugs don't occur with react-native-drawer-layout-polyfill.
In the demo, comment and uncomment the imports for switch the drawers.

Environment

• react: 16.6.3
• react-native: 0.57.8
• react-native-gesture-handler: 1.0.12
• phone: Nokia 5 Android 8.1

Demo

RNGH-DrawerLayout-Bug

[osdnk]

@brentvatne

[brentvatne]

thanks for putting effort into this issue! unfortunately I'm still having a hard time understanding because it feels like there are two issues together here.

1. Button appears above drawer. The Button component in react-native uses elevation which has the same effect as zIndex. We could perhaps set some elevation on the drawer on Android, or a zIndex. Does this make sense to you?
2. "The drawer is visible behind the dialog, this occur in special situations" - it's unclear to me why this isn't desirable. If you open a permissions dialog and the drawer is open, why would you hide the drawer?

[ahce]

@brentvatne Thanks for your reply.

1. Yes, the problem is the elevation, where zIndex is the fix.

2. Special situations are those reported in the steps of Form 1 and 2 where the drawer is closed.

Please test my repo RNGH-DrawerLayout-Bug

[ahce]

@brentvatne the bug when drawer is closed and is visible behind the alert, don't occur with useNativeAnimations set in false.
It is possible to set useNativeAnimations to false by default?

[brentvatne]

cc @kmagiera ^

[osdnk]

@ahce, I don't want to change useNativeAnimations to false. It's not a point of this library. Will try to figure it out

[ahce]

@brentvatne @osdnk I found an easier way to reproduce the bug. Check my repo RNGH-DrawerLayout-Bug (dependencies updated to the latest).
I also found a possible solution, they are changes in 3 lines (11, 73, 529), please check this.

[sign2k]

I am experiencing the same problem (using react-native-navigation 3.3.2 + react-native-gesture-handler 1.1.0). My app navigates to a new screen and checks some Android permissions after mounting the screen component.

PermissionsAndroid.requestMultiple([
                "android.permission.ACCESS_FINE_LOCATION",
                "android.permission.ACCESS_COARSE_LOCATION",
                "android.permission.BLUETOOTH",
                "android.permission.BLUETOOTH_ADMIN"])

The drawer appears behind the android action dialog although it should not be visible at all.
useNativeAnimations: false solves the problem but of course is not the best solution.

[ahce]

@sign2k Can you test this DrawerLayout?

[sign2k]

@sign2k Can you test this DrawerLayout?

Tested it - seems not to help in my case. I replaced the offical "DrawerLayout.js" with your file.

[ahce]

@sign2k
The problem occurs when there is a render after the dialog is opened.
In my repo, DrawerLayout as PureComponent avoids rendering when the keyboard is hidden, after trying to share the text, but it is not enough for all cases.

[m3dwards]

I've also got an app that requests permissions after navigating to a screen and it opens the drawer while the permission dialog is up.

[alburdette619]

I'm having this issue too. Should the missing info label be taken off? It seems like @ahce has verified it and the cause pretty well.

[nash2196]

What is the fix for this? This is still an issue.

[KAngel7]

I faced the same issue "the drawer appears behind the android action dialog" with "react-native-gesture-handler": "^1.2.0" and "react-navigation": "3.2.0" but some devices works and some are not. Not sure where it come from, please help

[cayodonatti]

Same problem here as of rn 0.61, rngh 1.4.1

[pravin-maan]

thanks
useNativeAnimations:false,
it's working

[CoolCola]

useNativeAnimations:false works, not the best, other solutions?

[fleidloff]

same here, any ideas? useNativeAnimation:false is not an option for us