ActionSheetIOS is drawn behind react-native-navigation's overlay

[ahwatts]

We have an app with a music player component, that is using react-native-navigation's "overlay" functionality. The issue we're seeing is that if the player is open, and you poke our floating add button, the ActionSheetIOS is drawn behind the overlay:

Before:

After:

After doing a bit of digging around, I found an issue on react-native-navigation here: wix/react-native-navigation#5024 , but I also want to cross-post here as the issue (to me) seems to lie a bit more on RN's side than RNN's side.

What appears to be going on (and pardon me because I'm not super familiar with iOS terminology or development) is that the overlay is implemented as a separate window on top of the main window. The ActionSheetIOS ultimately looks to the Key window to decide which window it will draw on top of. Since the overlay is on top of the main window, so long as the main window is the Key window, the action sheet will be drawn over the main window but under the overlay window.

There is a hack in RNN to set the overlay window as the Key window, but that fails as soon as the user focuses on a text field anywhere outside of the overlay. As soon as that happens, the overlay window is no longer the Key window, and the bug resurfaces.

It seems like the rule of displaying the action sheet on top of the Key window is incorrect in this case. The action sheet should instead be displayed on top of the frontmost window. I managed to fix this bug at least in my specific case by patching RCTActionSheetManager.m, line 76, like so:

But I'm obviously hesitant to actually use this patch beyond my development environment because I'm unsure of its ramifications. I'm also not really sure whose bug this is, RNN's or RN's, or if it even counts as a bug in the first place.

React Native version:
React Native Environment Info:
System:
OS: macOS 10.14.5
CPU: (8) x64 Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz
Memory: 397.67 MB / 16.00 GB
Shell: 5.0.7 - /usr/local/bin/bash
Binaries:
Node: 12.3.1 - /usr/local/bin/node
npm: 6.9.0 - /usr/local/bin/npm
Watchman: 4.9.0 - /usr/local/bin/watchman
SDKs:
iOS SDK:
Platforms: iOS 12.2, macOS 10.14, tvOS 12.2, watchOS 5.2
Android SDK:
API Levels: 25, 26, 27, 28
Build Tools: 26.0.1, 27.0.2, 27.0.3, 28.0.3
System Images: android-25 | Google APIs Intel x86 Atom, android-26 | Google APIs Intel x86 Atom, android-26 | Google APIs Intel x86 Atom_64, android-27 | Google APIs Intel x86 Atom, android-27 | Google Play Intel x86 Atom, android-28 | Google APIs Intel x86 Atom, android-28 | Google APIs Intel x86 Atom_64
IDEs:
Android Studio: 3.4 AI-183.6156.11.34.5522156
Xcode: 10.2.1/10E1001 - /usr/bin/xcodebuild
npmPackages:
react: 16.8.3 => 16.8.3
react-native: ^0.59.8 => 0.59.8
npmGlobalPackages:
react-native-cli: 2.0.1
react-native-git-upgrade: 0.2.7

[zhongwuzw]

@ahwatts 🤔 I may think it should be fixed in react-native-navigation, because it's reasonable that we find the VC in keyWindow.

[ahwatts]

The difficulty with fixing it that way is that in order for the action sheet to be drawn correctly, the overlay window needs to maintain key window status even if the main window grabs it back. There does seem to be callbacks associated with becoming and resigning the key window, but using those will lead to a bad user experience if they want to type input into the main window.

Ultimately, it seems to me that the key window indicates where input should go, not what window to draw on top of. Those appear to me to be separate concerns.

[zhongwuzw]

Yeah, I think it's so hard for us to change key window to last window, because last window also is not always what user wants. I may suggest you implement some native module, and control the key window when do something like present action sheet. What do you think? 🤔

[ahwatts]

I think what I'm going to go with is a sort-of clunky workaround. I'll hide the overlay when the share modal comes up, and then show it again when the share modal goes away. The user loses a bit of context when they hit the share button, but they can actually see the share modal.

[zhongwuzw]

👍 Yeah, it's the workaround what we can do currently, please let us know if you have any better way to handle ActionSheet presentation.