You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On Android (New Architecture / Fabric), when a MapView sits inside a react-navigation screen and that screen is detached and re-attached (e.g. the surrounding bottom-tab set changes while the user is on another screen), the native GoogleMap is recreated - onMapReady fires a second time for the same component instance. The mapPadding that was in effect is not re-applied to the recreated map: the value applied during the new view's mount is swallowed by the still-initializing map, and because the JS mapPadding prop is value-equal across renders, Fabric never re-sends it. The map is left with zero padding indefinitely - visibly, the native My Location button jumps to the raw top-right corner under the system status bar.
This looks like a residual case of the padding-application family fixed by #5151 (#5150 / #5152 / #5153): those fixes (contained in 1.28.2) cover the initial mount, but not a native map recreated after a screen re-attach.
Reproducible sample code
// Map screen registered inside a react-navigation bottom-tabs navigator// whose tab set changes while this screen is blurred (a conditional tab).importReactfrom'react';importMapView,{PROVIDER_GOOGLE}from'react-native-maps';exportdefaultfunctionMapScreen(){const[ready,setReady]=React.useState(false);return(<MapViewstyle={{flex: 1}}provider={PROVIDER_GOOGLE}showsUserLocationshowsMyLocationButtononMapReady={()=>{console.log('onMapReady');// fires AGAIN after the screen re-attachessetReady(true);}}mapPadding={ready ? {top: 120,right: 0,bottom: 0,left: 0} : undefined}initialRegion={{latitude: 42.7,longitude: 25.3,latitudeDelta: 1,longitudeDelta: 1}}/>);}
Steps to reproduce
Render the MapView above in a screen of a react-navigation bottom-tabs navigator, with the mapPadding top offset applied. The native My Location button renders below the offset (correct).
Navigate away (push a screen over the tabs), and while the map screen is blurred change the tab set (add or remove a conditional tab), so the map screen goes through a detach/re-attach.
Navigate back to the map screen.
Watch the console: onMapReady fires a second time - the native map view was recreated. The My Location button now renders under the status bar; the previously applied mapPadding is gone and never comes back (the JS prop value did not change, so Fabric dedupes it and nothing reaches the native side).
Expected result
The recreated native map retains (or re-applies) the mapPadding currently set on the component - the My Location button stays below the padding offset.
Actual result
The recreated map has zero padding; the My Location button renders under the system status bar and stays there indefinitely.
Workaround we ship: nudge the padding value by 1px inside onMapReady, forcing a post-init prop update Fabric cannot dedupe. Note for anyone else affected: anchoring the nudge on a navigation focus event is NOT reliable - it races the native map recreation (we reproduced both orderings on different devices); onMapReady is the deterministic signal that the recreated map can accept setPadding.
React Native Maps Version
1.28.2
What platforms are you seeing the problem on?
Android
React Native Version
0.86.0
What version of Expo are you using?
Not using Expo
Device(s)
Pixel 9 emulator (Android 16) and physical Android device
Additional information
Reproduced on react-native-maps 1.28.2, React Native 0.86.0, New Architecture (Fabric), googleRenderer LATEST.
Not fixed by upgrading: the 1.29.0 changelog contains no padding/restore-related changes.
Summary
On Android (New Architecture / Fabric), when a MapView sits inside a react-navigation screen and that screen is detached and re-attached (e.g. the surrounding bottom-tab set changes while the user is on another screen), the native GoogleMap is recreated -
onMapReadyfires a second time for the same component instance. ThemapPaddingthat was in effect is not re-applied to the recreated map: the value applied during the new view's mount is swallowed by the still-initializing map, and because the JSmapPaddingprop is value-equal across renders, Fabric never re-sends it. The map is left with zero padding indefinitely - visibly, the native My Location button jumps to the raw top-right corner under the system status bar.This looks like a residual case of the padding-application family fixed by #5151 (#5150 / #5152 / #5153): those fixes (contained in 1.28.2) cover the initial mount, but not a native map recreated after a screen re-attach.
Reproducible sample code
Steps to reproduce
mapPaddingtop offset applied. The native My Location button renders below the offset (correct).onMapReadyfires a second time - the native map view was recreated. The My Location button now renders under the status bar; the previously appliedmapPaddingis gone and never comes back (the JS prop value did not change, so Fabric dedupes it and nothing reaches the native side).Expected result
The recreated native map retains (or re-applies) the
mapPaddingcurrently set on the component - the My Location button stays below the padding offset.Actual result
The recreated map has zero padding; the My Location button renders under the system status bar and stays there indefinitely.
Workaround we ship: nudge the padding value by 1px inside
onMapReady, forcing a post-init prop update Fabric cannot dedupe. Note for anyone else affected: anchoring the nudge on a navigation focus event is NOT reliable - it races the native map recreation (we reproduced both orderings on different devices);onMapReadyis the deterministic signal that the recreated map can acceptsetPadding.React Native Maps Version
1.28.2
What platforms are you seeing the problem on?
Android
React Native Version
0.86.0
What version of Expo are you using?
Not using Expo
Device(s)
Pixel 9 emulator (Android 16) and physical Android device
Additional information
googleRendererLATEST.showsUserLocation) survives the recreation, so the loss is specific to the padding state, not the whole prop set.