[Android] mapPadding is lost when the native map is recreated on screen re-attach (onMapReady re-fires; value-equal prop is never re-sent)
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 52/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- android, react-native, typescript
- Domain
- mobile
Research direction
Start at the Android native MapView handling for onMapReady and mapPadding, then trace how setPadding behaves when the native GoogleMap is recreated after screen re-attach under Fabric. Reproduce the tab-detach scenario and verify that the recreated map retains the current padding without requiring a value-changing workaround.
Written by the indexing model from the issue text.
Description
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 - 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).
import React from 'react';
import MapView, { PROVIDER_GOOGLE } from 'react-native-maps';
export default function MapScreen() {
const [ready, setReady] = React.useState(false);
return (
<MapView
style={{ flex: 1 }}
provider={PROVIDER_GOOGLE}
showsUserLocation
showsMyLocationButton
onMapReady={() => {
console.log('onMapReady'); // fires AGAIN after the screen re-attaches
setReady(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
mapPaddingtop 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:
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 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),
googleRendererLATEST. - Not fixed by upgrading: the 1.29.0 changelog contains no padding/restore-related changes.
- Related prior work already contained in 1.28.2: #5151 (fixes #5150/#5152/#5153, initial-mount padding), #5727 (state-restore double-initialization).
- The user-location dot (
showsUserLocation) survives the recreation, so the loss is specific to the padding state, not the whole prop set.
- Dominant language
- TypeScript
- Stars
- 16k
- Forks
- 5k
- Avg merge
- 9d 9h
- Merged PRs (30d)
- 3
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from react-native-maps/react-native-maps
-
Difficulty 1/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
react-native-maps/react-native-maps#5987 · 1 comment ·
All issues in react-native-maps/react-native-maps
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
0xMiden/bridge-portal#132 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
area:tools bug good first issue help wanted priority:P2
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
TaewoooPark/Motifcode#14 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
newrelic-experimental/preflight#793 · 1 comment ·