As a user, I want my browser to remember its state on rotating the screen or memory eviction

[colintheshots]

As a user, I want my browser to remember the state of user interface input and state after I rotate the screen between portrait and landscape or when I return to the app after using many other apps so that my browser has has been evicted from memory.

Dependencies (Added by PM and Eng)

• No dependencies besides Fenix engineering

Next Steps

• Immediate task: Devote one engineer for 4-5 days to improve the core app architecture. A likely fix is either adding our existing ViewState to ViewModels or to custom retained fragments. Either way, the solution will also need the ability to save and restore instance state.

Acceptance Criteria (Added by PM)

• I can rotate the screen for most features of the app without losing user input or UI state.
• I can minimize and restore with the Don't Keep Activities developer setting set active for most features of the app without losing user input or UI state. Alternatively, a better way of testing is to minimize the app and run adb shell am kill org.mozilla.fenix and then launch the app from the recents screen.

┆Issue is synchronized with this Jira Task

[colintheshots]

I'm considering two options: ViewModels with the alpha Saved State module to provide save/restore functionality. The second option is to reinvent the wheel by designing a custom solution with retained fragments in order to reduce the amount of required boilerplate I'd need to add to our architecture. Retained fragments is how ViewModels work.

[colintheshots]

This is mostly fixed. As of PR#2382, the new Fenix architecture handles preserving state on rotation automatically. This is probably sufficient to have a successful MVP.

I'm going to create a new bug to cover the save and restore instance state functionality, which will require careful code design. We don't want save/restore to be fully automatic like our rotation and configuration changes solution is. We want our engineers to think about and specify which state becomes instance state because the OS provides quite limited space for storing state. We wouldn't, for example, want the bookmarks or history screens to store everything into saved instance state if it's likely we might use 1 MB or more of memory. That's because there's a hard limit at 1 MB and we really shouldn't use more than about 100 KB. Instance state is preserved in memory after the Android OS shuts down our app to make space in memory for another app.

Here is the new ticket for handling instance state:
#2418