Fenix: [Crash] IllegalStateException FragmentManager has been destroyed

[boek]

java.lang.IllegalStateException: 

  at androidx.fragment.app.FragmentManager.ensureExecReady (FragmentManager.java:4)

  at androidx.fragment.app.FragmentManager.execPendingActions (FragmentManager.java:1)

  at androidx.fragment.app.FragmentManager$4.run (FragmentManager.java:1)

  at android.os.Handler.handleCallback (Handler.java:873)

  at android.os.Handler.dispatchMessage (Handler.java:99)

  at android.os.Looper.loop (Looper.java:214)

  at android.app.ActivityThread.main (ActivityThread.java:7073)

  at java.lang.reflect.Method.invoke (Native Method)

  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:494)

  at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:964)

https://sentry.prod.mozaws.net/operations/fenix-nightly/issues/6457309/?query=is:unresolved%20ensureExecReady

[ekager]

Looks like STR here? https://github.com/mozilla-mobile/fenix/issues/8374

[ekager]

Also we probably only need one of these (looks the same as #8405 as well)

[pocmo]

STR for me:

• Put Fenix into private mode
• Open a custom tab
• Select "Open in Firefox Preview" from the menu

[pocmo]

With some logging I see that for some reason we recreate the browser activity on switching AND even create one that we immediately destroy. That is weird.

W  (+) onCreate(android.intent.action.MAIN): 265958844  // Launching Fenix
    |
W  (-) onDestroy(android.intent.action.MAIN): 265958844 // Switching to private mode: 
W  (+) onCreate(android.intent.action.MAIN): 133400951  // Recreating activity (to apply theme)
    |
    |    W  (+) onCreate(android.intent.action.VIEW): 249927606 // Launching custom tab
    |    |
    |    W  (-) onDestroy(android.intent.action.VIEW): 249927606 // Leaving custom tab after clicking "Open in Fenix"
    |
    |    W  (+) onCreate(android.intent.action.VIEW): 117827452  // Creating new activity?
    |    |
    |    W  (-) onDestroy(android.intent.action.VIEW): 117827452 // Destroying it immediately??
    |
W  (-) onDestroy(android.intent.action.MAIN): 133400951 // Destroying browser
W  (+) onCreate(android.intent.action.MAIN): 193142077  // Creating a new browser

• I wonder why we create this activity that we immediately destroy?
• I wonder why the browser activity gets destroyed and recreated after switching to the browser. Wrong theme?

When I comment out activity.recreate() in ThemeManager then this looks better and does not crash:

W  (+) onCreate(android.intent.action.MAIN): 187589969 // Launching Fenix
    |
    |    W  (+) onCreate(android.intent.action.VIEW): 57155225  // Launching custom tab
    |       |
    |    W  (-) onDestroy(android.intent.action.VIEW): 57155225 // Leaving custom tab

I wonder:

• Does the ThemeManager recreate too often (why do we have this activity that gets destroyed?)?
• Is there a theme switch needed at all when opening a (private) custom tab in fenix (also in private mode)?

I do not know what is happening to the fragment manager actually causing this crash. However in AC we have seen Activity.recreate() causing issues when being used with viewLifecycleOwner.lifecycleScope (the scope doesn't get cancelled in some situations). Maybe related. Maybe not.

[pocmo]

Looking at ThemeManager I see us twice determining we are in private mode but should be in normal mode which causes the recreate().

I also noticed that even though we show the custom tab in private tab colors, it is not actually a private tab (that doesn't seem right?) - which may be another reason why we try to switch to normal mode (although that should work too).

[liuche]

The relevant PR is here: https://github.com/mozilla-mobile/fenix/pull/8740

[ekager]

I think we'll need to verify #8637 and then keep an eye on Sentry in Nightly to verify all crashes with this trace have been fixed

[sv-ohorvath]

This crash trace reported on #8637 doesn't reproduce anymore with the STR provided. Although, https://github.com/mozilla-mobile/fenix/issues/8374#issuecomment-591336307 seems that it's still crashing but with a different error.
@ekager should I leave this open until Sentry reports confirm it?

[severinrudie]

Closing as this was verified