fix: remove NavView fragment via the FragmentManager it is attached to - #625
Conversation
NavViewManager.onDropViewInstance removed the map/navigation fragment through reactContext.getCurrentActivity()'s support FragmentManager. When the view is dropped while getCurrentActivity() points at a different Activity than the one hosting the fragment (e.g. after Activity recreation), that FragmentManager never hosted the fragment and androidx throws: IllegalStateException: Cannot remove Fragment attached to a different FragmentManager Use the fragment's own getParentFragmentManager() for the remove transaction instead, and guard against the FragmentManager being already destroyed mid-teardown. This also no longer skips cleanup (leaking the fragmentMap entry) when getCurrentActivity() is null.
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
| .beginTransaction() | ||
| .remove((Fragment) fragment) | ||
| .commitNowAllowingStateLoss(); | ||
| // Remove via the FragmentManager the fragment is actually attached to. |
There was a problem hiding this comment.
We don't need to explain the earlier functionality in the comments. Also considering that the code is pretty straight forward I think this whole comment can be removed.
|
Hey @christian-apollo. It seems you have signed the CLA, but there was an error. Could you please amend your commit and remove the Also please see my comment above. |
Requested in review: the code is straightforward and the comment mostly explained the previous behavior.
d77c873 to
45c8186
Compare
4 participants
Fixes #624
Problem
NavViewManager.onDropViewInstanceremoves the map/navigation fragment throughreactContext.getCurrentActivity().getSupportFragmentManager(). The fragment was attached to whichever Activity was current when the fragment transaction was committed. IfgetCurrentActivity()points at a different Activity at drop time — e.g. after Activity recreation while the original host is still alive — that FragmentManager never hosted the fragment, and androidx throws a fatal:BackStackRecord.removethrows exactly whenfragment.mFragmentManager != null && fragment.mFragmentManager != mManager, i.e. when the transaction's FragmentManager is not the one the fragment is attached to.Fix
Open the remove transaction on the fragment's own
getParentFragmentManager(), which is by definition the FragmentManager the fragment is attached to, so the mismatch can no longer occur.isAdded()is checked first, sogetParentFragmentManager()cannot throw for a detached fragment; a remainingIllegalStateException(FragmentManager already destroyed mid-teardown) is caught, since in that case the fragment is torn down with its host Activity anyway.This also removes the early return when
getCurrentActivity()is null — the current Activity is no longer needed for removal, and returning early leaked thefragmentMapentry.When the current Activity is the fragment's host (the common case),
getParentFragmentManager()andactivity.getSupportFragmentManager()are the same instance, so behavior is unchanged.Testing
com.apolloscootersand have been shipping this exact change via patch-package on top of 0.16.3; the crash signature is eliminated by construction.:googlemaps_react-native-navigation-sdk:compileDebugJavaWithJavacpasses with the change applied.🤖 Generated with Claude Code