+++ This bug was initially created as a clone of Bug #1287330 +++

(In reply to Kris Maglione [:kmag] from comment #250) > It's been one of my worst Fennec pain points lately... Out of curiosity, in what way exactly? Fennec already has infrastructure for creating lazily-loaded tabs, which is used for everything but the selected foreground tab when automatically restoring tabs on startup and also for freeing up memory under memory pressure. From skimming over bug 1287330 and 906076 it seems that our implementation is a bit less sophisticated, though, since we simply swap in an "about:blank" browser and expect any other code to just deal with that, which is probably mostly the case give this behaviour has been around for a while now [1]. Any interesting piece of state that we want to preserve is stashed away in the session store data. There might still be some benefit in switching over to the new implementation, but I want to be sure you're aware that we already have something similar which needs to be taken into account. [1] Although I think I've just noticed that our selectOrAddTab/getTabWithURL logic doesn't handle this case correctly.

(In reply to Jan Henning [:JanH] from comment #1) > (In reply to Kris Maglione [:kmag] from comment #250) > > It's been one of my worst Fennec pain points lately... > > Out of curiosity, in what way exactly? > Fennec already has infrastructure for creating lazily-loaded tabs, which is > used for everything but the selected foreground tab when automatically > restoring tabs on startup and also for freeing up memory under memory > pressure. We lazily load the actual tab content, but we still eagerly insert the browser, and therefore eagerly create the initial about:blank docshell. For a small number of tabs, and under light load, that doesn't make much difference, but the more tabs you have, the more it adds up. For me, it often gets to the point where it takes more than a minute to begin displaying the active tab when I first open the browser.

Right - in that case it would indeed be nice to get this working for Fennec's "zombie" tabs as well.

Skimming some more through the history of this on Desktop, it seem that Fennec slept through the switch to TabStateCache, which would probably be required for this.

One further possible complication: On Desktop, the whole UI is in XUL, so apart from the <browser>s for the content we also have <tab>s for displaying the tab bar. This means that the tab events can be dispatched on the actual XUL <tab>s (and all tabs can be watched via an event listener on the parent <tabs> element) and you don't have to care about what happens to the individual <browser>s. Fennec on the other hand uses a native UI and therefore has only <browser>s, but no XUL-<tab>s (only plain tab JS objects, plus corresponding representations on the Java side). So instead, all tab events are dispatched on a tab's <browser>, which might a bit problematic for tabs with unlinked browsers.

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.