I am trying to render elements conditionally where each element has different zIndex style property.
Using folowing code in Android emulator with react-native 0.30.0.
import React, { Component } from 'react';
import { StyleSheet, Text, View } from 'react-native';
export default class Demo extends Component {
constructor(props, ctx) {
super(props, ctx);
this.state = {
showGreen: true,
};
}
render() {
return (
<View style={{flex: 1, padding: 20}}>
<View style={[styles.item, {zIndex: 3, backgroundColor: 'red'}]}>
<Text>zIndex: 3</Text>
</View>
{this.state.showGreen &&
<View style={[styles.item, {zIndex: 2, backgroundColor: 'green'}]}>
<Text>zIndex: 2</Text>
</View>
}
<View style={[styles.item, {zIndex: 1, backgroundColor: 'blue'}]}>
<Text>zIndex: 1</Text>
</View>
<View style={styles.button}>
<Text onPress={() => this.setState({ showGreen: !this.state.showGreen })}>
Toggle green
</Text>
</View>
</View>
);
}
}
const styles = StyleSheet.create({
item: {
marginTop: -20,
height: 50,
paddingTop: 22,
},
button: {
backgroundColor: 'gray',
marginTop: 30,
}
});
Initial screen looks like expected:
When I click 'Toggle green' button to dynamically show/hide green element it hides blue element instead and furthermore element's text is missing:
When I click the button again, red and green elements remains visible and the toggle button jumps down.
Still an issue in 0.32.
It seems that zindex breaks component unmounting.
any news?
Same thing happened to me, so I'll throw in some more details:
In iOS, returning null
makes the element disappear.
In Android, you have to reduce the height to 0 and remove borders.
What is worse is that you can't stick to a single solution, because Android's workaround won't work for iOS. The element will just show up again.
Here's the code for a component that does this sort of thing:
import React from 'react';
import {
Image,
Platform,
StyleSheet,
Text,
TouchableOpacity,
View
} from 'react-native';
import { default as closeIcon } from "../img/closeIcon.png";
const ReadFullArticleFloatingBox = ({visible, opacity = 0, title, onPressRead, onPressClose}) => {
let conditionalLayout = visible ? {} : styles.hidden;
return Platform.OS === "ios" && !visible ? null : (
<View style={[styles.container, conditionalLayout, { opacity }]}>
<View style={styles.leftContainer}>
<Text numberOfLines={1} style={styles.title}>{title}</Text>
<TouchableOpacity onPress={onPressRead} style={styles.readButton}>
<Text style={styles.readButtonText}>READ FULL ARTICLE</Text>
</TouchableOpacity>
</View>
<TouchableOpacity onPress={onPressClose} style={styles.icon}>
<Image
resizeMode={Image.resizeMode.contain}
style={styles.iconImage}
source={closeIcon}
/>
</TouchableOpacity>
</View>
);
};
const styles = StyleSheet.create({
container: {
height: 60,
position: "absolute",
zIndex: 2,
left: 0,
right: 0,
marginTop: 20,
paddingHorizontal: 10,
borderTopWidth: 1,
borderBottomWidth: 1,
borderColor: "lightgrey",
backgroundColor: "white",
flexDirection: "row",
alignItems: "center",
justifyContent: "center"
},
hidden: {
zIndex: -2,
height: 0,
borderTopWidth: 0,
borderBottomWidth: 0
},
leftContainer: {
flex: 1,
padding: 6
},
title: {
fontSize: 13,
fontFamily: "CrimsonText-Roman",
color: "#46474C"
},
readButton: {
paddingVertical: 6
},
readButtonText: {
fontFamily: "Roboto",
color: "teal",
fontSize: 11
},
icon: {
width: 40,
height: 40,
alignItems: "center",
justifyContent: "center",
padding: 10
},
iconImage: {
width: 20,
height: 20
}
});
export default ReadFullArticleFloatingBox;
+1, happened to me in a similar situation.
If it's helpful to anyone, I created a Hideable
component to handle this:
import React, { Component } from 'react';
import {
View,
StyleSheet,
Platform
} from 'react-native';
const hideable_styles = StyleSheet.create({
android_hidden: {
height: 0,
borderWidth: 0,
paddingTop: 0,
paddingBottom: 0,
marginTop: 0,
marginBottom: 0
}
});
class Hideable extends Component {
render(){
const {hide, children, style = {}, ...rest_props} = this.props;
// on ios, best way to hide is to return null
if (hide && Platform.OS === 'ios') return null;
// otherwise, if android, going to add in the special android hidden styles
const conditional_layout = hide ? hideable_styles.android_hidden : {};
const styles = [style, conditional_layout];
return (
<View {...rest_props} style={styles}>
{children}
</View>
);
}
}
export default Hideable;
Here's a simple use:
const simpleTestHideable = ({hide = true}) => {
return (
<Hideable hide={hide} style={{zIndex: 1, backgroundColor: 'red', height: 100}} >
<Text>{hide ? 'You should not see this' : 'You should see this' }</Text>
</Hideable>
);
}
Here's a more complex, interactive usage example:
class TestHideable extends Component {
constructor(props){
super(props);
this.state = { hide_content: false };
this.toggleContent = this.toggleContent.bind(this);
}
toggleContent(){
this.setState({hide_content: !this.state.hide_content});
}
render(){
const { hide_content } = this.state;
return (
<View style={{paddingTop: 20}}>
<Hideable
hide={hide_content}
anotherProp="foo"
style={{
padding: 10,
height: 100,
borderWidth: 0.5,
borderColor: '#d6d7da',
marginTop: 100,
marginBottom: 100,
backgroundColor: 'red',
zIndex: 2
}} >
<Text>I am showing!</Text>
</Hideable>
<Text onPress={this.toggleContent}>{hide_content ? 'SHOW!' : 'HIDE!'}</Text>
</View>
)
}
}
export default TestHideable;
You should be able to pass through whatever styles or props you'd like to Hideable
's View
, make it animatable, etc.
Also, @tioback, I noticed you set a negative zIndex
, is that something you recommend? It's worked for me without it but I wasn't sure if it was needed for certain devices or certain use cases. I also noticed that on my device I had to remove the vertical margins and padding as well, so there may be other styles to watch out for.
I'm still pretty new to React Native so, grain of salt.
@liamfd no, I don't recommend for, nor against it. Might be some left-over from a failed test.
Nice component, BTW.
Hi,
TL;DR;
If you have array of components with zIndexes, and then one of them dynamically removed (becomes null by state change for ex.), instead of reordering the remaining components, the removed one still "partially" remains in the viewport and covers everything underneath by white area.
Details:
I'm struggling with the same issue. Afaik, zIndex only reorders the Views on native, but seems that whenever the element becomes null (removed from the tree), it still overlaps all the elements that had lower zIndex at some point, even though this "newly becoming null" element doesn't have it's own zIndex as it doesn't have styles anymore.
So this means that the element is not removed completely when it's set to null, because the green color in the initial example still stays.
It's a huge problem for me, because I'm building cross-platform app and I'm trying to have as much shared code between Web and Native as possible. I'm using react-router, so I have few <Match>
components as siblings. To implement animated transitions between pages I'm using react-motion, that basically sets component to "null" at the end of some spring animation when it's not matching the route. Assuming that I cannot control the order of <Match>
components (because they're in a separate route config which is again shared between Web and Native), it causes the issue that if I go from the last page to previous one, the last one becomes "null" at the end of animation and jumps to the front layer. All pages are absolutely positioned and fullscreen, so in result I see the full white screen, because this "null" element overlaps everything. It's not a best option for me to use workaround like <Hideable>
, because it's platform agnostic, and my goal is to have this animated transitions as a shared component, as well as the react-router <Match>
'es.
Here is slightly modified example using three absolutely positioned elements, each subsequent of them have lower zIndex, so red is on top (60px height), green is underneath (90px height), and the blue is underneath (120px height). When the green is removed, the expected behaviour would be that green is completely removed from subviews, the remaining two elements would have their zIndex (order) recalculated, so we would see only red and blue underneath it.
But instead the green one stays alive, and even covers the blue element with "invisible" white overlay. (The same I see in my app with the routes described above). And it occurs ONLY when dynamically remove this green element. If I initially set the flag to false, it doesn't appear which is correct.
Modified example in the fresh react-native app 0.37.0:
import React, { Component } from 'react';
import {
AppRegistry,
StyleSheet,
Text,
View
} from 'react-native';
export default class zindex extends Component {
constructor(props) {
super(props);
this.state = {
showGreen: true
};
}
render() {
return (
<View style={{flex: 1}}>
<View style={[styles.item, {zIndex: 3, backgroundColor: 'red'}]}>
<Text>zIndex: 3</Text>
</View>
{this.state.showGreen ?
<View style={[styles.item, {zIndex: 2, backgroundColor: 'green', height: 90}]}>
<Text>zIndex: 2</Text>
</View> : null
}
<View style={[styles.item, {zIndex: 1, backgroundColor: 'blue', height: 120}]}>
<Text>zIndex: 1</Text>
</View>
<View style={styles.button}>
<Text onPress={() => this.setState({ showGreen: !this.state.showGreen })}>
Toggle green
</Text>
</View>
</View>
);
}
}
const styles = StyleSheet.create({
item: {
position: 'absolute',
left: 0,
right: 0,
top: 0,
height: 60
},
button: {
position: 'absolute',
left: 0,
right: 0,
backgroundColor: 'gray',
top: 150,
height: 30
}
});
AppRegistry.registerComponent('zindex', () => zindex);
Starting page:
Result:
Expected behaviour:
Not sure how I will proceed with this issue, but I will keep posting any ideas if I find them.
Update 1: If I initially put the showGreen to false, then add it by toggling the button, everything is fine. I suspect that the views are reordered by zIndex only when they're added, but not when they're removed. Might it be related to this commit ? In the ViewGroupManager.java and ReactViewManager.java the reordering is not called on removeViewAt, might this be a problem? I'm not a Java expert though, would appreciate if someone could have a closer look at this particular case.
Yo I'm the author of that commit :)
@asgvard Thanks for the fantastic bug reporting. I think you're right, check out:
I think the fix is as simple as matching the addView
method so it looks like:
public void removeViewAt(T parent, int index) {
parent.removeViewAt(index);
reorderChildrenByZIndex(parent)
}
I don't really have the bandwidth to PR a fix and test it right now, but you probably could :) It's a good first PR.
@tuckerconnelly Hey :) So today I made a try to fix this issue with simply adding the reorderChildrenByZIndex(parent);
in removeViewAt
for ViewGroupManager
, but unfortunately it didn't helped. As I mentioned I'm not a Java developer, so I took some simple steps to debug this by using Logs. I added a accessibilityLabel
to my <View>
's so I can easily see which one is logged in Java code with view.getContentDescription()
.
Here is my modified JS code:
<View accessibilityLabel="RED" style={[styles.item, {zIndex: 3, backgroundColor: 'red'}]}>
<Text>zIndex: 3</Text>
</View>
{this.state.showGreen ?
<View accessibilityLabel="GREEN" style={[styles.item, {zIndex: 2, backgroundColor: 'green', height: 90}]}>
<Text>zIndex: 2</Text>
</View> : null
}
<View accessibilityLabel="BLUE" style={[styles.item, {zIndex: 1, backgroundColor: 'blue', height: 120}]}>
<Text>zIndex: 1</Text>
</View>
<View accessibilityLabel="BUTTON" style={styles.button}>
<Text onPress={() => this.setState({ showGreen: !this.state.showGreen })}>
Toggle green
</Text>
</View>
The result leads me to even more deep problem. From JS prospective I'm removing Green view, but in Java it actually tries to remove Blue:
11-15 00:30:59.657 12091 12091 I REORDER : Indice to remove: 1
11-15 00:30:59.657 12091 12091 I REORDER : Tag to delete: 8 which is: GREEN
11-15 00:30:59.657 12091 12091 I REORDER : manageChildren in NativeViewHierarchyManager...
11-15 00:30:59.657 12091 12091 I REORDER : indexToRemove: 1
11-15 00:30:59.657 12091 12091 I REORDER : viewToRemove: BLUE ID: 12
11-15 00:30:59.657 12091 12091 I REORDER : removeViewAt in ViewGroupManager invoked for index: 1
11-15 00:30:59.657 12091 12091 I REORDER : Children before removing:
11-15 00:30:59.657 12091 12091 I REORDER : 0 child is: BUTTON
11-15 00:30:59.657 12091 12091 I REORDER : 1 child is: BLUE
11-15 00:30:59.657 12091 12091 I REORDER : 2 child is: GREEN
11-15 00:30:59.657 12091 12091 I REORDER : 3 child is: RED
11-15 00:30:59.657 12091 12091 I REORDER : Children after removing:
11-15 00:30:59.657 12091 12091 I REORDER : 0 child is: BUTTON
11-15 00:30:59.657 12091 12091 I REORDER : 1 child is: GREEN
11-15 00:30:59.657 12091 12091 I REORDER : 2 child is: RED
11-15 00:30:59.657 12091 12091 I REORDER : Reordering started...
11-15 00:30:59.657 12091 12091 I REORDER : Queued to reorder: BUTTON
11-15 00:30:59.657 12091 12091 I REORDER : Queued to reorder: GREEN
11-15 00:30:59.657 12091 12091 I REORDER : Queued to reorder: RED
11-15 00:30:59.658 12091 12091 I REORDER : Reordering end...
11-15 00:30:59.658 12091 12091 I REORDER : view is bringed to front: BUTTON
11-15 00:30:59.658 12091 12091 I REORDER : view is bringed to front: GREEN
11-15 00:30:59.658 12091 12091 I REORDER : view is bringed to front: RED
Seems that in NativeViewHierarchyManager
in the method manageChildren
it uses indexes to remove views, but since the indexes changed internally in Java (after reordering by zIndex from [RED, GREEN, BLUE, BUTTON]
to [BUTTON, BLUE, GREEN, RED]
), and JS doesn't know about it, maybe it's more reliable to remove by tags? Because tagsToDelete contain the correct one, which is 8 (GREEN), and 12 is BLUE.
Also this bug might lead to another unexpected things because dropView
is still called on GREEN :) So basically the BLUE is removed
from view manager, but GREEN get dropped.
Will post any updates.
Cheers
UPDATE:
First of all, I found out that it has nothing to do with the reorderChildrenByZIndex() at all, because we actually don't need to reorder children after we remove something, because the relative zIndex order for remaining items remain the same. The problem was exactly in that it was removing the wrong View
by it's index in the array.
Fixed by relying on tagsToDelete
instead of indicesToRemove
in manageChildren
method of NativeViewHierarchyManager
. Because after reordering we cannot rely on the item index in the ViewGroup
, but the tag
seems to be reliable way of identifying the View
anytime. I think the similar reason of using tagsToDelete
was applied here.
Also this issue happens when Adding views, it adds them in the wrong index :) But since after adding the views we're doing reorder again, it doesn't matter that it was added into the wrong place.
So the proposed solution is to change manageChildren
method, so it will first make a loop by tagsToDelete
, perform removeView()
on all the tagsToDelete
, then after the cleanup of all the nodes to delete, we perform a loop by viewsToAdd
and that's it. It will remove the huge chunk of code from here to here, because essentially all it's doing is viewManager.removeViewAt(viewToManage, indexToRemove);
only in the case if the node is not animated and not in the tagsToDelete
array. So instead we could just move this responsibility to the loop by tagsToDelete
.
I will prepare PR soon :)
@asgvard Legend! Thanks!
Seems this PR brakes few unit tests (yes I should've double-checked that :) ), will investigate why it failed and prepare another one.
Ok so seems initial idea of just using tagsToDelete
instead of indicesToRemove
wasn't good. Because actually indicesToRemove
consists the nodes that were moved from somewhere, plus the nodes to delete completely. So instead I propagated tagsToRemove
from UIImplementation, because it's exactly the same as indicesToRemove
, but in our case tag
is more reliable way to safely remove nodes.
Any updates on this issue?
@mvf4z7 Just keep track of this PR:
https://github.com/facebook/react-native/pull/10954
My local Android unit and integration tests passed. Circle and Travis CI failed for some unrelated reasons, so as soon as someone from Reviewers could have a look into this, maybe we will have it merged. I wouldn't mind to have it asap as well ;)
Any updates on this issue?
any updates?
I'm experiencing this also, zIndex
+ position:absolute
breaks in android
I'm still experiencing this just for the record!
me to, any update?
same here, zIndex
+ position : absolute
, any update ?
Instead of return null
I just return <View />
and it works fine for me on both Android and iOS.
any updates on this? I am also experiencing this bug, with zIndex
+ position : absolute
on android
Created product pain: https://react-native.canny.io/feature-requests/p/zindex--positionabsolute-breaks-with-dynamic-components-on-android
If the title and/or post can be clarified, I'm all for it.
Same issue here 馃ぃ
Experiencing the same issue here, but even with position: relative.
I was able to fix this by using a Modal component, but I need the rest of the screen to be touchable, and Modals are fullscreen so I could not use that either.
Thanks!
I am using Modal from react-native and when I close it (set visible to false), it makes my other components disappear one by one. First close navbar, second close a card. Both has elevation and zIndex set.
@rnowm Can you share your fix with Modal?
Glad I'm not the only one having issues with this (zIndex + position: absolute). I've been trying to statically set zIndex's, but then realized I could just ditch zIndexing my absolute views and just reorder them in my render return so that they stay on top. I know this will not fix most of the problems of those who actually need to use zIndex but hopefully it helps someone.
@Gumija in my case I just needed one component with z-index (a toast) over my view, maybe that's why it worked for me. Did not tested with other elements using z-index.
Same issue here
I'm also having an issue with zIndex
+ position: 'absolute'
on Android. I have a dropdown menu component that always displays the currently selected item, and when it is activated, it also displays a list of all of the available dropdown menu items below this. The view that this dropdown menu is used in has other components as siblings of the dropdown menu component, and they are all after the dropdown menu component, since I want the currently selected item of the dropdown menu component to be shown first.
I'm trying to use zIndex
so that the list of the available dropdown menu items is shown above the other components that are rendered after the dropdown menu. I'm simply applying a zIndex: 2
to the <View>
that contains this list of available dropdown menu items to achieve this. The list of available dropdown menu items is rendered within a <View>
that has position: 'absolute'
.
This technique is working perfectly on iOS and behaves exactly as I expect/want. However, the exact same code is not working on Android; The list of available dropdown menu items is always rendered behind the other components that are rendered after the dropdown menu, and therefore is not visible. I've tried all sorts of variations of zIndex
values for different components in the hierarchy, as well as elevation
, and nothing seems to make this work on Android, even though it works fine on iOS.
Something must be different about how zIndex
works in iOS vs Android, as the same code behaves differently in these two environments.
Same here.
Problem's still here
same here.
Adding "elevation: 100" to the style solved my issue.
credit goes to Shukarullah Shah
Same issue here, everything works as expected without a zIndex (It just doesn't look right) Once I add a zIndex of 1 it goes to shit.
One tip that might be helpful:
You might get away with changing the rendering order instead of using zIndex. This only works on elements under the same parent though.
i got same issue on android, add loading component with absolute + zIndex. It will cause unexpected rendering on that screen (such as some components disappear or white out all screen or some components) and stop the app from working. I have tried all solution mention above such add elevation: 100 and move loading component to the last component in the view. But the issue still happens on android.
https://gist.github.com/nhuthuynh/009dee73675c1dbed41d34a86b359057
"react": "^16.0.0-alpha.6",
"react-native": "^0.43.4",
Genymotion: 2.9.0
Virtual Device: Google Nexus 5X 1080x1920
Got the same problem here ! After reading the discussions and skimming through the code I realized that the root problem lies in the current implementation of zIndex
which is basically invoking bringToFront()
on the child views in order of their zIndex. ( It is done in ViewGroupManager.reorderChildrenByZIndex()
method)
This method spoils the natural index of child views in their parent. Therefore indicesToRemove
parameter in NativeViewHierarchyManager.manageChildren
will no longer refer to the actual child.
@asgvard did a beautiful job in PRs (#10954) trying to use tag-reference instead of child-index. However @astreet suggested the problem is better be solved fundamentally by migrating to a zIndex
implementation mechanism that doesn't mess with child-view indices (probably using android's ViewGroup#getChildDrawingOrder
).
It seems like 23 days ago @janicduplessis fixed zIndex mechanism in commit 9a51fa8. When I used react-native source from master branch everything was working just fine.
Hope this commit goes on the next release !
actually, elevation property worked on android, just remove zIndex property on android platform and make the component with elevation property is the last component.
ios: {
zIndex: 1
},
android: {
elevation: 1
},
it works for me! thank all!
@nhuthuynh but elevation adds shadow
@brkyldz : because it will affect z-order in android as it document mentioned : " Sets the elevation of a view, using Android's underlying elevation API. This adds a drop shadow to the item and affects z-order for overlapping views. Only supported on Android 5.0+, has no effect on earlier versions."
Closing this since it is now fixed (sorry for not posting here I didn't know about this issue).
This will make it in RN 0.45 (May) which should be in RC in a few days.
@janicduplessis I' working on an app that is currently using RN 0.45.1 and it has a View with 3 images inside. I need left and right images to be on top of the center image, so I set a zIndex to the left image so its placed on top of the center one. It does not work. It only works when instead of using zIndex, I use elevation in Android. This way it does work, but I get the warning error saying Warning: Failed prop type: Invalid props.style key `elevation` supplied to `RCTImageView`.
This is my code
<View
style={{
flex: 2,
justifyContent: 'center',
alignItems: 'center',
flexDirection: 'row',
}}
>
<Image
source={require('./image_left.png')}
style={{ top: 60, left: 50, elevation: 1 }} // zIndex doesn't work
/>
<Image source={require('./image_center.png')} />
<Image
source={require('./image_right.png')}
style={{ top: 100, left: -65 }}
/>
</View>
BTW, this is what I'm trying to do
@janicduplessis I am still having this issue. I uploaded a screencast for ios, android, and even uwp(windows). Android is funky. I was on 0.45.1
but then I ran react-native-git-upgrade
and then react-native start
then react-native run-android
but I am having same issue, even though I am now at 0.46.1
. I uploaded screencasts in a stackoverflow issue here please - https://stackoverflow.com/questions/45021849/zindex-not-working-on-android-0-46-but-does-on-ios-and-even-uwp-windows
Can confirm what others have mentioned. I added the following to my style.alert and it works on both platforms now.
...Platform.select({
ios: {zIndex: 9999},
android: {elevation: 100}
})
Thanks for your case @jaredmharris. However using elevation
is not the same as zIndex
, as pointer-events pass through what is underneath. elevation
also causes a shadow to be created.
still no solution for the Zindex issue on android?
I think the issue is that zIndex was not updated properly after the view was mounted. #15203 should fix it, let me know if you can test it and it fixes your problem.
A sincere thank you for trying your hand to fix it @janicduplessis - it is a blocker issue for the app I am working on.
I simply solved this very quickly by creating two identical style objects and one of them doesn't have the zIndex , I chose what style to be served through the Platform checker.
<View style={platform({ ios: styles.overlayContaineriOs, android: styles.overlayContainerAndroid })} >
still seeing this issue, I have a listview that when triggered overlays over some other components. Everytime the listview is activated and overlays over the components then is deactivated (removing the overlay) one component dissappears each time.
@janicduplessis I am experiencing maybe a similar zIndex related issue:
here is the code : code sample demonstrating the issue
the image has zIndex:1
, i am unable to press the close button .
If i remove zIndex
from the image than i can press the close button .
The fix has not been released yet, it will make it in the next RC release (no eta on when this will happen)
After one year and this error is still exists.
I'm using 0.44.0
If a view has zIndex
, then a modal, after closing this modal, the view will be disappear.
This is should be mark as critical error and need to be fixed asap.
@jaredmharris @Noitidart Anyway to prevent pointer-events pass through while using elevation
?
Fortunately I did not have to deal with pointer-events with my code. I popup an alert on the screen that disappears after a few seconds.
Are you using a Modal component? You shouldn't need to set zIndex/elevation for that. Make sure the order of your components are ordered correctly. Children components appear on top of parent components so see if you can change things up to get it to work.
@Tom29 I could not find a way to make pointer-events pass using elevation
alone. I would have to include state senstive logic to reorganize the order of elements to make sure my element i need on top is rendered bottom most.
@jaredmharris Yes, i'm using modal, then after closing it, view with zIndex
will be disappeared.
This is so annoying bug on Android :(
Many thank, i've changed the order or view component instead of using zIndex
until this bug fixed.
For anyone still stuck on the old RN here's a function I use that can be spread into your styles. It's based on the ideas presented by others above:
function zIndexWorkaround(val: number): Object {
return Platform.select({
ios: {zIndex: val},
android: {elevation: val}
});
}
Use it like this in place of e.g: zIndex: 100
...zIndexWorkaround(100)
Remove the Flow type checking from the function if you don't need it
@glenn-axsy and others reading his comment, just a warning: elevation
is not a one-to-one solution for zIndex
. For me it never worked how I needed it, I would get shadows when I didn't, and also the pointerEvents order was incorrect.
My RN version is 0.49.5 and I've encountered the same issue when setting the position
to absolute
. My workaround is rearranging the components, whose orders are based on the zIndex
. This may introduce some chaos but should be a better approach than setting the elevation
.
My react-native version is 0.49.3 and I am still encountering this problem with the zIndex and the elevation in android. I also used the @glenn-axsy workaround but still couldn't solve the issue.
In the image below I want the user icon on top of the View but it is hiding and not coming on the top as expected
Why this issue is closed? zIndex still not working on Android, and elevation is not the solution, because of mess of pointer-events.
Issue exists with react-native version 0.50.3
Works fine on iOS, compatibility issues with Android.
still not working on Android :/
Invalid props.style key elevation supplied to Image.
you can finish the work without zIndex
It is still not working! this is a mess. I was using zindex but not using is not the solution
+1. Works great on ios, breaks views in android
@janicduplessis
any update?
Issue exists with react-native version 0.51.0 too
damm work great in IOS but in ANDROID crash , any update ?
It's been unresolved for too long, any updates?
0.51.0
Works as expected on IOS.
On android neither zIndex nor elevation works for me.
pretty disappointing.
0.52.1
having the same issue
still occur on [email protected]
0.54.0
The problem still exists
please check this newly opened issue. It has a repo that reproduces the problem.
v0.54.2
Still a problem.
Still having this issue with v0.55.2
still
Can we just agree that this issue needs to be reopen NOW?
Still exist in v0.55.4
Yep, having the same issue still. Even setting as absolute, the component will never render on top of the components, always will be hidden by the parent component.
Most helpful comment
I'm experiencing this also,
zIndex
+position:absolute
breaks in android