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)
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)
Updated•1 year ago
|
Comment 1•1 year ago
|
||
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.
Comment 2•1 year ago
|
||
First crashes on Nightly closely correlate with the landing of https://github.com/mozilla-mobile/fenix/pull/25991
Reporter | ||
Updated•1 year ago
|
Comment 3•1 year ago
|
||
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.
Reporter | ||
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Comment 4•1 year ago
|
||
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.
Comment 5•1 year ago
|
||
Updated•1 year ago
|
Reporter | ||
Updated•1 year ago
|
Reporter | ||
Comment 7•1 year ago
|
||
Mihai, is your crash fix safe to uplift to Beta 110?
PR merged to 111 main: https://github.com/mozilla-mobile/fenix/commit/f0f1da69b8b5d558915e69655a933368bc3374be
Comment 8•1 year ago
|
||
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.
Reporter | ||
Comment 9•1 year ago
•
|
||
(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:
Reporter | ||
Comment 10•1 year ago
|
||
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
Comment 11•1 year ago
|
||
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.
Reporter | ||
Comment 12•1 year ago
|
||
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
Updated•1 year ago
|
Comment 13•1 year ago
|
||
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).
Comment 14•1 year ago
|
||
Updated•1 year ago
|
Comment 15•1 year ago
|
||
: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?
Comment 16•1 year ago
|
||
Closing this as fixed in 111. Will follow up with the second PR if needed after the current fix gets in release.
Updated•1 year ago
|
Updated•1 year ago
|
Comment 17•1 year ago
|
||
QE if the team can check if this crash volume decreases a week after the release of 111 around March 21st.
Comment 18•1 year ago
|
||
Updated•1 year ago
|
Updated•1 year ago
|
Reporter | ||
Comment 20•1 year ago
|
||
@ 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
Reporter | ||
Updated•1 year ago
|
Reporter | ||
Comment 22•1 year ago
|
||
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)
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Comment 23•11 months ago
|
||
Mihai, are you still working on this one? Thanks
Comment 24•11 months ago
|
||
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.
Updated•11 months ago
|
Updated•11 months ago
|
Comment 25•9 months ago
|
||
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?
Comment 26•9 months ago
|
||
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.
Reporter | ||
Comment 27•9 months ago
|
||
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.
Reporter | ||
Comment 28•9 months ago
|
||
About 88% of these crash reports are from Android 7 and 7.1 devices.
Updated•9 months ago
|
Updated•9 months ago
|
Comment 29•9 months ago
|
||
Reporter | ||
Comment 30•3 months ago
|
||
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.
Reporter | ||
Updated•2 months ago
|
Updated•2 months ago
|
Updated•2 months ago
|
Updated•1 month ago
|
Updated•1 month ago
|
Updated•23 days ago
|
Comment 31•19 days ago
|
||
Can QE help verify STR for this crash on an Android 7 device: when does this popEntryFromBackStack occur with tab history?
Comment 32•16 days ago
|
||
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.
Updated•16 days ago
|
Updated•6 days ago
|
Description
•