1303394 - Think about making tabs count caching less dependent on home panel initialisation order

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: Awesomescreen, defect)

Description

[Jan Henning [:JanH]]

Bug 1302424 has unfortunately shown that the home panel adapter can be initialised before the panelStateChangeListener is available.

This means that in those instances the caching effectively won't be effective, since we only read the cached value if we can pass it to the history adapter in its constructor, since we normally have to update some other things and cannot avoid an animation if we change the value afterwards.

It also means that in those instances the closed tabs count won't even necessarily be cached at all in the first place, since we only attempt to cache the value when it is updated - if the panelStateChangeListener isn't available immediately after initialisation (when the only guaranteed updates happen while we read the sessionstore file and receive closed tabs from Gecko), we won't cache the tabs count, so if no further updates happen further on (because the tab count changes while the home panels are actually loaded and the panelStateChangeListener is hopefully finally available), we never store a cached value.

However, it might still be relatively safe to directly manipulate the recentTabsCount of the HistoryAdapter as long as the RecyclerView hasn't yet been intialised (https://dxr.mozilla.org/mozilla-central/rev/edfff7a9e4c43f6d516dfbf69a64e205e5cdb699/mobile/android/base/java/org/mozilla/gecko/home/CombinedHistoryPanel.java#143). That would extend the window of opportunity to set the cached closed tabs count from onCreate() to onViewCreated().

We'd then also have to think about saving the closed tabs count when the panelStateChangeListener is set if we haven't been able to cache the value during the actual initial tabs count update process.

Otherwise we'd need to find a different way to store the cached tabs count which would have to be guaranteed to be available in the history panel's onCreate() function.

Since I can't reproduce this issue on my phone, I'd ideally need somebody who could help in testing this.

Possible STR:
1. Have some recently closed tabs, so the smart folder displays.
2. Open a new tab with any URL.
3. Click into the address bar to enter editing mode and show the home panels. Switch to the history panel if it isn't your default panel already.
4. Exit editing mode so the home panels close again, then re-enter it, which should take you to the history panel again.

If after step 4, the Recently closed folder is immediately visible, the caching works. Otherwise, if it inserted with an animation (even if this happens immediately after opening the home panel) each time the home panels are opened, the caching doesn't work for your device.

Comment 1

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.