Nested main tabs are more trouble than they're worth
Fedilab apparently stores each tab switch in a history list, which is used for the back button functionality. But there's two major problems with this:
When using the back button, newer versions of the same tab are lost, overwritten by the older versions when they're recalled. In busy timelines, this will cause toots from the newer versions to not be loaded in the older ones, hiding them behind a "Load more toots" thing instead. This makes it harder than it needs to be to find toots from the newer timeline versions in case we accidentally hit the back button or whatever.
This also causes slowdowns as more pages build up. On my 2016 Galaxy J7 Prime, even just 5 tabs in the history (i.e. going from one tab to another using the buttons up top 4 times) will make Fedilab have a noticeable delay when using the Delete & Redraft function. With a dozen pages, it ends up taking several seconds to activate it. Faves & boosts are slightly faster, but they also show noticeable delays.
This functionality isn't even necessary, tbh. Since all the tabs are right there at the top, there's no real point to having more than one instance of, say, the home timeline stored in RAM. This back button history functionality only needs to be applied to the sub pages like profiles, conversations, and the stuff in the left-hand menu. When on the main screen, it should just exit, regardless of tab.
In terms of how to handle the main tabs overall, you only need to store one version of each tab and update it when refreshing that tab, adjusting the saved user position accordingly so as to not have the UI jump about and stay on the toots that the user is currently viewing.
Steps for reproducing the issue
Use the buttons at the top to go back and forth between tabs. As new toots get loaded for each one, it'll slow down on its own.
- GNU Social
Version of Fedilab: 1.75.0
Android version: 4.4.2, 5.1.1, 7.0