[Bug]: The application crashes after deleting the last inactive tab displayed in the list

[delia-pop]

Steps to reproduce

1. Have a few tabs opened.
2. Make them inactive.
3. Go to tabs tray and expand the inactive tabs list.
4. Tap on the "X" button on the right of the last tabs from the list.
5. Observe that the application closes unexpectedly.

Expected behaviour

The application should remain stable.

Actual behaviour

The application crashes after deleting the last inactive tab displayed in the list.
However, crash reports are created in About Firefox > Crashes.

Device name

Google Pixel 6, Lenovo Yoga Tab 11

Android version

Android 13, Android 11

Firefox release type

Firefox Nightly

Firefox version

Nightly 109.0a1 from 11/25

Device logs

108.0b4.txt
Nightly109.11.25.txt
Fenix_CrashReport.txt

Additional information

Note that the issue does not have a 100% repro rate.
Reproducible on Beta 108.0b4 as well.
Could not be reproduced on Release.

screen-20221125-170853_Trim.mp4

┆Issue is synchronized with this Jira Task

[MozillaNoah]

Drive by: I was able to reproduce this locally, but only by:

1. Marking at least 2 tabs as inactive. One tab HAS to be the currently open tab and it has to be the last tab in the list.
2. Closing the very last tab in the inactive tabs list (e.g. the tab that is currently open)

So the key detail may be closing an inactive tab that is currently open.

I can confirm that the uncaught exception is: PlacesApiException$UnexpectedPlacesException, as listed in the above text files.

[MatthewTighe]

I will continue to investigate, but I'm curious about 2 things:

1. Is this reproducible if the last inactive tab is not the selected tab?
2. Is this reproducible if tabs become inactive naturally and are not forced to be inactive?

[MatthewTighe]

It looks like this is only reproducible if the last inactive tab is the currently selected tab. That state should not be reproducible in production channels as the selected tab will not become inactive even after the 2 week period has gone by.

Since this is an edge case only reproducible on debug builds, I will close this as wont-fix for now. If there are reproducible steps I can follow for a release build, please feel free to re-open and we will continue investigation 🙂

[MatthewTighe]

For clarity, I tried the following things:

Using a release beta build, I opened several tabs and then changed the device time to be 4 months in the future. The last selected tab was still active, and the others were inactive. Closing the last inactive tab from that list did not reproduce the bug.

Using a debug build built from today's main, I forced several tabs to be inactive including the selected tab. I then opened a different, new tab. Closing the last inactive tab (the previously selected one) did not reproduce the bug.

[MatthewTighe]

It turns out this menu option is still accessible if the user has the secret settings menu available. Given that, I am re-opening for now in case Product would like to prioritize this

[delia-pop]

Tested with latest Nightly 111.0a1 from 01/18 with Lenovo Yoga Tab 11 (Android 11). The following were observed:

1. the original issue is fixed: even if the last inactive tab is also the last selected tab, the app won't crash after deleting it;
2. an exception is made if the inactive tab deleted a child page opened from the parent tab. In this case, after opening a link from the parent page > accessing the child page so that it would be the last selected tab >making both the parent and child tabs inactive > deleting the child page from the inactive tabs list (which is also the last inactive tab displayed in the list) > will crash the app.

please observe the screen recording:

inactive_child_page.mp4

I could not reproduce the crash when the parent page is deleted.
@DreVla should I open a separate ticket for the latest reproducible scenario? In the meanwhile I will remove the QA Needed label.

[delia-pop]

@DreVla explained how in normal conditions, an user will no longer be able to have all the tabs inactive. The last accessed tab will remained active, thus the scenario I mentioned above is no longer valid, since it involved using the debug feature to manually make all tabs inactive.
Closing this as verified fixed.