Open Bug 1804377 Opened 1 year ago Updated 6 days ago

Crash in [@ java.lang.IllegalStateException: at androidx.navigation.NavController.popEntryFromBackStack(NavController.kt:180)] Attempted to pop Destination(org.mozilla.firefox:id/tabHistoryDialogFragment), which is not the top of the back stack

Categories

(Fenix :: History, defect, P2)

Unspecified
Android

Tracking

(firefox107 wontfix, firefox108 wontfix, firefox109 wontfix, firefox110 wontfix, firefox111 wontfix, firefox112 wontfix, firefox113 wontfix, firefox114 wontfix, firefox115 wontfix, firefox116 wontfix, firefox117 wontfix, firefox123 wontfix, firefox124 wontfix, firefox125 wontfix, firefox126 wontfix)

Tracking Status
firefox107 --- wontfix
firefox108 --- wontfix
firefox109 --- wontfix
firefox110 --- wontfix
firefox111 --- wontfix
firefox112 --- wontfix
firefox113 --- wontfix
firefox114 --- wontfix
firefox115 --- wontfix
firefox116 --- wontfix
firefox117 --- wontfix
firefox123 --- wontfix
firefox124 --- wontfix
firefox125 --- wontfix
firefox126 --- wontfix

People

(Reporter: cpeterson, Unassigned)

References

Details

(Keywords: crash, regression, topcrash, Whiteboard: [fxdroid] [geckoview:m111] [geckoview:m112] [group4])

Crash Data

Attachments

(3 files, 1 obsolete file)

I think this crash is a regression in Fenix 107.

Crash report: https://crash-stats.mozilla.org/report/index/4e214c68-ec4a-41b3-9ec9-1667e0221206

Java stack trace:

java.lang.IllegalStateException: Attempted to pop Destination(org.mozilla.fenix:id/tabHistoryDialogFragment), which is not the top of the back stack (Destination(org.mozilla.fenix:id/tabHistoryDialogFragment))
	at androidx.navigation.NavController.popEntryFromBackStack(NavController.kt:180)
	at androidx.navigation.NavController.popEntryFromBackStack$default(NavController.kt:7)
	at androidx.navigation.NavController$NavControllerNavigatorState.pop(NavController.kt:102)
	at androidx.navigation.fragment.DialogFragmentNavigator.popBackStack(DialogFragmentNavigator.kt:95)
	at androidx.navigation.fragment.DialogFragmentNavigator$$ExternalSyntheticLambda1.onStateChanged(R8$$SyntheticClass:189)
	at androidx.lifecycle.LifecycleRegistry$ObserverWithState.dispatchEvent(LifecycleRegistry.java:15)
	at androidx.lifecycle.LifecycleRegistry.backwardPass(LifecycleRegistry.java:86)
	at androidx.lifecycle.LifecycleRegistry.sync(LifecycleRegistry.java:38)
	at androidx.lifecycle.LifecycleRegistry.moveToState(LifecycleRegistry.java:50)
	at androidx.lifecycle.LifecycleRegistry.handleLifecycleEvent(LifecycleRegistry.java:10)
	at androidx.fragment.app.FragmentStateManager.stop(FragmentStateManager.java:43)
	at androidx.fragment.app.FragmentStateManager.moveToExpectedState(FragmentStateManager.java:158)
	at androidx.fragment.app.FragmentManager.executeOpsTogether(FragmentManager.java:1178)
	at androidx.fragment.app.FragmentManager.removeRedundantOperationsAndExecute(FragmentManager.java:92)
	at androidx.fragment.app.FragmentManager.execPendingActions(FragmentManager.java:74)
	at androidx.fragment.app.FragmentManager$5.run(FragmentManager.java:4)
	at android.os.Handler.handleCallback(Handler.java:751)
	at android.os.Handler.dispatchMessage(Handler.java:95)
	at android.os.Looper.loop(Looper.java:154)
	at android.app.ActivityThread.main(ActivityThread.java:6682)
	at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1520)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1410)

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

  • Top 10 AArch64 and ARM crashes on beta
  • Top 10 AArch64 and ARM crashes on release

For more information, please visit auto_nag documentation.

Keywords: topcrash

First crashes on Nightly closely correlate with the landing of https://github.com/mozilla-mobile/fenix/pull/25991

Flags: needinfo?(mcarare)

I will look into this.

Seems like more than 98% of the crashes occur on Android 7 devices. The remaining, not on Android 7 are tv-boxes.

Assignee: nobody → mcarare
Whiteboard: [fxdroid]

Update on the state of investigating this:

I have not been able to reproduce this, and I have requested some colleagues from QA that have an Android 7 device to also try to reproduce it.

One thing that pops up from looking into the sentry data is that there is almost a 1:1 ratio between the crash event number and the number of users affected. This suggests that it is not a permanent failure of the feature, but an occasional interference from another event. My first guess would be that it might have to do with some CFR or pop-up we only show once. I will continue the investigation in this direction.

On the other hand, if it is a one-time-crash per user, the good thing is that it does not make the app unusable permanently / frequently.

Flags: needinfo?(mcarare)
Whiteboard: [fxdroid] → [fxdroid] [geckoview:m111]
Rank: 111

Chris, is an uplift planned for 110? Thanks

Flags: needinfo?(cpeterson)

Mihai, is your crash fix safe to uplift to Beta 110?

PR merged to 111 main: https://github.com/mozilla-mobile/fenix/commit/f0f1da69b8b5d558915e69655a933368bc3374be

Status: NEW → RESOLVED
Closed: 1 year ago
Flags: needinfo?(cpeterson) → needinfo?(mcarare)
Resolution: --- → FIXED

I haven't considered uplifting because it is a speculative fix and I wanted to see if we get any more crashes in the nightlies after the merge.

Flags: needinfo?(mcarare)

(In reply to Mihai Adrian Carare [:mcarare] from comment #8)

I haven't considered uplifting because it is a speculative fix and I wanted to see if we get any more crashes in the nightlies after the merge.

We haven't received any reports of this crash since Nightly 110's Jan 6 build, so we'll have to wait a little longer to see if your fix (which landed on Jan 17) fixed the crash. The crash rate in Release is pretty high (about 3500 crash reports from Fenix 108), so uplifting a fix to Beta 110 would be good.

Here's my crash report query for Fenix Nightly:

https://crash-stats.mozilla.org/signature/?release_channel=nightly&signature=java.lang.IllegalStateException%3A+at+androidx.navigation.NavController.popEntryFromBackStack(NavController.kt%3A180)&date=>%3D2023-01-01T00%3A00%3A00.000Z

Reopening this bug because we just received two crash reports from build ID 20230127094652, after Mihai's fix landed in 2023-01-06. So Mihai's fix doesn't seem to have totally addressed the issue.

https://crash-stats.mozilla.org/report/index/7a69687c-6266-4646-8d36-481e50230128

https://crash-stats.mozilla.org/report/index/d394bcf8-fa31-4747-9dc5-23d270230128

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

FYI, the commit was merged on main only on 2023-01-17: https://github.com/mozilla-mobile/fenix/commits/main?after=921ef6e40a7b5a1e650be5de659191244feec9b8+69&branch=main&qualified_name=refs%2Fheads%2Fmain so it would be integrated into Nightly builds only after that date.

We have some crashes from builds after 2023-01-17, such this crash from buildID 20230202091542:

https://crash-stats.mozilla.org/report/index/a2d60e0a-cf2e-4331-a931-7f81d0230203

Whiteboard: [fxdroid] [geckoview:m111] → [fxdroid] [geckoview:m111] [geckoview:m112]

I am considering waiting for the fix to ride the beta/ release trains for a more accurate view of the impact the previous fix made.
It seems to me like the crash rate dropped on Nightly, but the initial low volume on this channel makes me want to have more data. Depending on that I will remove or keep the current fix. (and try to work on another one).

:mcarare can we resolved this bug as fixed in 111?
There hasn't been any recent crashes in nightly or beta since this landed.
Would it be cleaner to track your follow-up Pr in a different bug?

Flags: needinfo?(mcarare)

Closing this as fixed in 111. Will follow up with the second PR if needed after the current fix gets in release.

Status: REOPENED → RESOLVED
Closed: 1 year ago1 year ago
Flags: needinfo?(mcarare)
Resolution: --- → FIXED
Attachment #9318760 - Attachment is obsolete: true

QE if the team can check if this crash volume decreases a week after the release of 111 around March 21st.

Flags: qe-verify+

Marking the ticket as verified fixed for 111.

Status: RESOLVED → VERIFIED
Target Milestone: --- → 111 Branch

@ Mihai, this bug was marked as fixed in 111, but I'm going to reopen it because we're still receiving crash reports with this crash signature and a very similar one (bug 1826372) in 111, 112, and 113.

https://crash-stats.mozilla.org/report/index/254dba88-c21c-4df0-94a2-2fced0230405

Status: VERIFIED → REOPENED
Crash Signature: [@ java.lang.IllegalStateException: at androidx.navigation.NavController.popEntryFromBackStack(NavController.kt:180)] → [@ java.lang.IllegalStateException: at androidx.navigation.NavController.popEntryFromBackStack(NavController.kt:179)] [@ java.lang.IllegalStateException: at androidx.navigation.NavController.popEntryFromBackStack(NavController.kt:180)]
Flags: needinfo?(mcarare)
Resolution: FIXED → ---
See Also: → 1826372
Duplicate of this bug: 1826372
See Also: 1826372

Moving this bug to the History component because this is a bug in the tabHistoryDialogFragment:

java.lang.IllegalStateException: Attempted to pop Destination(org.mozilla.firefox:id/tabHistoryDialogFragment), which is not the top of the back stack (Destination(org.mozilla.firefox:id/tabHistoryDialogFragment))
	at androidx.navigation.NavController.popEntryFromBackStack(NavController.kt:180)
	at androidx.navigation.NavController.popEntryFromBackStack$default(NavController.kt:7)
	at androidx.navigation.NavController$NavControllerNavigatorState.pop(NavController.kt:102)
	at androidx.navigation.fragment.DialogFragmentNavigator.popBackStack(DialogFragmentNavigator.kt:95)
	at androidx.navigation.fragment.DialogFragmentNavigator$$ExternalSyntheticLambda1.onStateChanged(R8$$SyntheticClass:189)
	at androidx.lifecycle.LifecycleRegistry$ObserverWithState.dispatchEvent(LifecycleRegistry.java:15)
	at androidx.lifecycle.LifecycleRegistry.backwardPass(LifecycleRegistry.java:86)
	at androidx.lifecycle.LifecycleRegistry.sync(LifecycleRegistry.java:38)
	at androidx.lifecycle.LifecycleRegistry.moveToState(LifecycleRegistry.java:50)
	at androidx.lifecycle.LifecycleRegistry.handleLifecycleEvent(LifecycleRegistry.java:10)
	at androidx.fragment.app.FragmentStateManager.stop(FragmentStateManager.java:43)
	at androidx.fragment.app.FragmentStateManager.moveToExpectedState(FragmentStateManager.java:158)
	at androidx.fragment.app.FragmentManager.executeOpsTogether(FragmentManager.java:1178)
	at androidx.fragment.app.FragmentManager.removeRedundantOperationsAndExecute(FragmentManager.java:92)
	at androidx.fragment.app.FragmentManager.execPendingActions(FragmentManager.java:74)
	at androidx.fragment.app.FragmentManager$5.run(FragmentManager.java:4)
	at android.os.Handler.handleCallback(Handler.java:751)
	at android.os.Handler.dispatchMessage(Handler.java:95)
	at android.os.Looper.loop(Looper.java:154)
	at android.app.ActivityThread.main(ActivityThread.java:6823)
	at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1563)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1451)
Component: General → History
Flags: needinfo?(mcarare)
Target Milestone: 111 Branch → ---

Mihai, are you still working on this one? Thanks

Flags: needinfo?(mcarare)

I am looking into this, but not actively working on a solution, as I do not have STRs to reproduce it.
I was expecting that the latest library upgrades would fix the issue, but not I am not seeing any changes in the crash stats numbers yet.

Assignee: mcarare → nobody
Flags: needinfo?(mcarare)

Looks like this is an Android 7-focused issue. Are we going to choose to let it continue until we eventually drop support for Android 7?

Flags: needinfo?(mcarare)

This also seems to affect specific devices in Android 7 and we haven't been able to reproduce it. As such, I do not see any fix other than refactoring the tab history view to Compose.
Not sure if we intend to drop support for Android 7 soon, AFAIK just 5 or 6 were discussed at some point.

Flags: needinfo?(mcarare)

Do we have plans to eventually move the tab history to Compose? Or should we close this bug as WONTFIX?

Android 7 and 7.1 (API 24 and 25) are about 9% (3.5% + 5.5%) of our user population, so we probably don't want to abandon them at this time.

https://sql.telemetry.mozilla.org/queries/80030#198699

Crash Signature: [@ java.lang.IllegalStateException: at androidx.navigation.NavController.popEntryFromBackStack(NavController.kt:179)] [@ java.lang.IllegalStateException: at androidx.navigation.NavController.popEntryFromBackStack(NavController.kt:180)] → [@ java.lang.IllegalStateException: at androidx.navigation.NavController.popEntryFromBackStack(NavController.kt:179)] [@ java.lang.IllegalStateException: at androidx.navigation.NavController.popEntryFromBackStack(NavController.kt:180)] [@ java.lang.Ille…

About 88% of these crash reports are from Android 7 and 7.1 devices.

Assignee: nobody → giorga
Status: REOPENED → ASSIGNED

The Android team has not been keeping our P1 bug list up to date, so we're resetting all our P1 bugs to P2 to avoid signalling that we're actively working on bugs that we're not. The BMO documentation https://wiki.mozilla.org/BMO/UserGuide/BugFields#priority says P1 means "fix in the current release cycle" and P2 means "fix in the next release cycle or the following (nightly + 1 or nightly + 2)".

If you are actively working on this bug and expect to ship it in Fx 122 or 123, then please restore the priority back to P1.

Priority: P1 → P2
Crash Signature: [@ java.lang.IllegalStateException: at androidx.navigation.NavController.popEntryFromBackStack(NavController.kt:179)] [@ java.lang.IllegalStateException: at androidx.navigation.NavController.popEntryFromBackStack(NavController.kt:180)] [@ java.lang.Ille… → [@ java.lang.IllegalStateException: at androidx.navigation.NavController.popEntryFromBackStack(NavController.kt:177)] [@ java.lang.IllegalStateException: at androidx.navigation.NavController.popEntryFromBackStack(NavController.kt:179)] [@ java.lang.Ille…
Whiteboard: [fxdroid] [geckoview:m111] [geckoview:m112] → [fxdroid] [geckoview:m111] [geckoview:m112] [group4]
Assignee: giorga → nobody
Status: ASSIGNED → NEW

Can QE help verify STR for this crash on an Android 7 device: when does this popEntryFromBackStack occur with tab history?

Flags: qe-verify+

I wasn't able to find clear steps to reproduce this crash.
I've tried getting to the crash by trying different actions around tab history, and CFR-s that I understood might help reproducing this issue.
Device used: Huawei P9 Lite (Android 7).
Tested builds: RC124.1.0, Beta 125.0b9, Nightly 126.0a1 from 2024-04-08.

Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: