<AnotherView />
<ViewOnTop />
Instead of
<ViewOnTop />
<AnotherView />
You can also use strategies like conditional display: "none" instead of unmounting/remounting.
Similar issues
It looks like z-index behavior on Android is not a new discussion: facebook/react-native#35565 . What was surprising to me was the fact that Reanimated can be the culprit. As in my app, z-index works just fine on Android with the latest react-native until you have an Animated.View with entering/exiting.
Some other people also realized that on their apps this was the cause: facebook/react-native#35565 (comment)
If it helps, I also found these similar old issues:
#3368 (mentioned on the comment I linked)
#3124 (iOS specific)
Looks like those are solved but since they are of a similar nature, it can be helpful in the process of finding the cause.
Steps to reproduce
On Android, position Views with position:absolute on top of each other strictly based on z-index - So the View on top is rendered first but z-index ensures it's on top anyways.
Trigger a layout animation on an Animated.View with the entering/exiting props
Try to unmount and remount the view with higher z-index multiple times
Snack or a link to a repository
https://snack.expo.dev/@leonardorib/layout-animations-and-zindex-issue-on-android (Reanimated 3.6.2)
https://github.com/leonardorib/layout-animation-and-z-index-issue (Reanimated 3.7.1)
Reanimated version
3.6.2, 3.7.1
React Native version
0.73.4
Platforms
Android
JavaScript runtime
Workflow
Architecture
Build type
Device
Device model
Samsung Galaxy M14 (Android 14)
Acknowledgements
## Summary
This PR fixes the bug that was causing z-index to behave incorrectly on
Android after a layout animation was triggered. The issue was that
sometimes our layout animation implementation was causing `removeView`
to be called more than once for the same view. This is not a problem on
plain Android, since there is a conditional check there for removal.
However, react-native's implementation of `ReactViewGroup` does not
check if the view is a part of this `ViewGroup` when handling removal.
The handler code decreases the counter, that maintains the number of
views that have 'z-index' defined by the user. Calling `removeView` too
many times causes the counter to go into negative numbers, causing react
to disable custom z-index order, even when there are views with user
defined z-index.
We decided to add an additional check when calling the `removeView`
function in `AnimationsManager.java`. There is a possibility we could
remove it altogether, but as of now this is not certain and requires
further investigation.
closes #5715
## Test plan
Check if the repro from #5715 works properly
Summary:
I was recently working on an [issue](software-mansion/react-native-reanimated#5715) in Reanimated where z-index of some views was broken after a Layout Animation was used. The issue was that in some cases we were calling the `removeView` function on a already removed view. On plain Android this wouldn't be an issue, since the `removeView` function ignores such calls. Unfortunately, the `ReactViewGroup.java` implementation maintains a counter of views with user defined z-index. This counter is decremented whenever a call to `removeView` is made, even if the view is not a child of this `ViewGroup`. This PR adds an additional check in the `handleRemoveView` function to unify the `removeView` behavior between Android and react-native.
## Changelog:
[ANDROID] [CHANGED] - Changed the `handleRemoveView` function in `ReactViewGroup.java` to ignore calls for `Views` that are not children of this `ViewGroup`
Pull Request resolved: #43389
Test Plan: I tested if the `rn-tester` app behaves correctly after those changes.
Reviewed By: NickGerleman
Differential Revision: D54874780
Pulled By: javache
fbshipit-source-id: f1a34947419ef6106ee73b196ae99b7f8c2f7a77
