2066925 - Crash showing a Snackbar after the Fragment has detached (HomeFragment, TabManagementFragment)

Status: NEW

(Firefox for Android :: General, defect)

Description

[Julie De Lorenzo [:jdelorenzo]]

IllegalStateException when snackbar code touches a Fragment that has detached or whose view has been destroyed.

1. TabManagementFragment — detached coroutine calls back into the Fragment. TabManagerController.handleBookmarkSelectedTabsClicked launches on CoroutineScope(ioDispatcher) deliberately, so the bookmark save survives leaving the screen (see its comment). But the completion callback re-enters the Fragment: showBookmarkSnackbar → getString() → getResources() → requireContext().

at androidx.fragment.app.Fragment.requireContext(Fragment.java:16)
at androidx.fragment.app.Fragment.getString(Fragment.java:10)
at ...TabManagementFragment$showBookmarkSnackbar$1.invokeSuspend(TabManagementFragment.kt:36)

handleSyncedTabClosed has the same shape, and showCollectionSnackbar also appears in the data.

2. HomeFragment — observer bound to the Fragment lifecycle, handler touches the view lifecycle. registerCollectionStorageObserver() registers with this, not viewLifecycleOwner. A Fragment outlives its view, so onTabsAdded can fire while the view is destroyed and then read viewLifecycleOwner (HomeFragment.kt:956).

at androidx.fragment.app.Fragment.getViewLifecycleOwner(Fragment.java:14)
at org.mozilla.fenix.home.HomeFragment.showComposeSnackbar(HomeFragment.kt:5)
at org.mozilla.fenix.home.HomeFragment$collectionStorageObserver$1.onTabsAdded(HomeFragment.kt:39)

3. SnackbarData.performAction — stale action lambda. The user taps the snackbar action after the originating fragment is gone; the captured lambda calls findNavController().

at androidx.fragment.app.Fragment.getParentFragmentManager(Fragment.java:14)
at androidx.navigation.fragment.FragmentKt.findNavController(Fragment.kt:18)
at org.mozilla.fenix.browser.BrowserFragment$$ExternalSyntheticLambda9.invoke(...)
at mozilla.components.compose.base.snackbar.SnackbarData.performAction(Snackbar.kt:3)

Volume. 40 of 200 crashes sampled from the R8 outline bucket. 28 distinct install_time values across 40 reports (1.43 per install). Seen on 154.0, 154.0.1, 155.0b3 and 156.0a1.

Samples: 5353f784-2ff8-4d93-b968-145040260819 (bookmark, 156.0a1), 371c252d-aa36-4c38-89ab-32e000260819 (HomeFragment observer, 156.0a1), 6734081c-8c3d-4433-a2b8-e97030260819 (performAction, 154.0)

Not a 154 regression — these appeared in earlier versions under requireContext / getViewLifecycleOwner / getParentFragmentManager signatures; 154 only changed the grouping. The signature's top frame is an R8 outline and groups several unrelated bugs, see bug 2059483; counts above come from re-clustering traces, not the signature.`

Comment 1

[BugBot [:suhaib / :marco]]

The bug is linked to a topcrash signature, which matches the following criterion:

• Top 10 AArch64 and ARM crashes on beta

:boek, could you consider increasing the severity of this top-crash bug?

For more information, please visit BugBot documentation.

Comment 2

[BugBot [:suhaib / :marco]]

Based on the topcrash criteria, the crash signature linked to this bug is not a topcrash signature anymore.

For more information, please visit BugBot documentation.

Comment 3

[Jonathan Almeida [:jonalmeida]]

Julie, these looks like three distinct causes across three different components. Should the be separated out further or can either the owning tabs tray or home screen team fix them all? The the combined crash rates look pretty high and we should burn them down if we can't separate out the signatures clearly for now.

Comment 4

[Julie De Lorenzo [:jdelorenzo]]

I've filed some separate bugs, and put up a patch for the TabManagementFragment ticket. For now I'm leaving this one open with the "dependsOn" fields set.