2011312 - Scope tab group use cases and persistence to a specific tab partition

Status: ASSIGNED

(Firefox for Android :: Tabs, task, P3)

Description

[Gabriel Luong [:gl] (ΦωΦ)]

Received some feedback from Jon and Christian that we should be conservative with how we expose use cases that interacts with tab partitions and persist BrowserState.tabPartitions.

In feature-tabs, we are able to be a bit more application specific and opinionated compare to concept- and other components due to the fact that we are implementing features. Currently, in TabsUseCases, we have exposed a partition: String as a parameter that can be specified by the consumer with TabPartitionTags. One feedback received was that we should not expose partition as a parameter since we can end up in a state where we incidentally add a TabPartition with the wrong key (eg, imagine manually specifying a partition value that is not actively used), and as a result, we would've created and persisted a TabPartition that will never be used by the application. This can result in some consequences that can result in crashes or data loss - if we ever needed to migrate our storage or modify BrowserState parameters and data structure, and need to also migrate existing user data to the new structure without totally understanding what data is persisted (eg unknown TabPartition). The idea here is to make everything that we are storing and the Tab Partition that are created to be explicit and strictly controlled.

Furthermore, there's no limit to the amount of TabPartition that can be created and persisted to disk. A concern already raised in https://phabricator.services.mozilla.com/D278353#9673027 about persisting more data to disk than what we may want. We should instea make sure we are able to specify the TabPartition that we want to persist to avoid persisting unwanted data.

To mitigate against misuse of creating unwanted TabPartition and persisting it, we want to harden how partition is specified. This can be achieved by having the use cases already take a hardcoded TabPartition key that is known in feature-tabs. In addition, we need to add the ability to specify the TabPartition key that should be persisted to disk to avoid persisting data that we may not want to write to disk. Essentially, we want the feature to know about the TabPartition that it is creating. Fetching data from this TabPartition can be done using extension functions so that consumers aren't reading the BrowserState.tabPartitions map directly - the point of this is still to guard against creating and reading the wrong TabPartition so we make this as simple for the consuming application by providing all the helpers and guardrails necessary to prevent misuse. Finally, we want to be able to specify the TabPartition that should be saved instead of defaulting to saving everything in BrowserState.tabPartitions.

Comment 1

[Gabriel Luong [:gl] (ΦωΦ)]

Attachment: Bug 2011312 - Part 1: Scope tab group use cases to a specific tab partition

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/ff0a6dce73e7
https://hg.mozilla.org/integration/autoland/rev/73fc8b9acb15
Part 1: Scope tab group use cases to a specific tab partition r=android-reviewers,007

Comment 3

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/73fc8b9acb15