2073219 - Integrate the Tab Data Coordinator into TabManagementFragment

Status: RESOLVED FIXED

(Firefox for Android :: Tabs, task)

Description

[Noah Bond [:007]]

With the tab data coordinator landed, it's ready to be integrated into various parts of Firefox. To thoroughly vet this code path, let's integrate it into the Tab Management Fragment.

As part of this ticket:

• Remove as many direct calls to BrowserState as possible from within the Fragment.
• Change TabStorageMiddleware to be a passthrough switchboard layer and move all of its data update code to DefaultTabDataCoordinator.
• Add any and all relevant unit tests for testing the implementation and the integration.

Goal

• Move data updates out of the Tabs tray UI layer and Redux layer.
• Set up the coordinator to be the centralized place for observing basic tab data and performing basic tab data updates.

Comment 1

[Noah Bond [:007]]

Attachment: Bug 2073219 - Part 1 - Add write APIs to Tab Data Coordinator

This commit adds the scaffolding for performing tab data write operations. This allows Coordinator to be the orchestrator for updating tab data and handling side effects which update multiple layers of tab data.

A result of this was expanding the APIs of the TabRepository contract. The coordinator will invoke TabRepository to perform tab metadata operations, such as moves, deletes, and additions. The implementation of TabRepository, Fenix's DefaultTabRepository implements them with TabsUseCases.

Tab now also carries the favicon and last access time so consumers can render a tab without reaching back into browser-state. The Bitmap is the same instance BrowserStore holds and is never copied.

The lookups a consumer needs to reason about group membership are added as
TabsSnapshot query extensions, and FakeTabRepository moves to main sources next
to FakeTabGroupRepository so the fakes can be shared with Fenix tests.

Comment 2

[Noah Bond [:007]]

Attachment: Bug 2073219 - Part 2 - Migrate the Tab Manager's tab data observations to the coordinator

The middleware now collects TabDataCoordinator.tabsSnapshot instead of performing its own Flow transformation + collection.

TabsSnapshotMapper handles the transformation from TabsSnapshot to TabStorageUpdate. We can further tear down the transformation if we only need specific slices of data, such as needing tab group data returned but not private tabs.

Because the coordinator is initialized with the application and keeps its
snapshot warm, the tray no longer has to wait for the first transformation after
it opens, and TabManagementFragment can size the inactive tabs auto-close dialog
and the private browsing lock banner from the snapshot.

The transformation tests move from TabStorageMiddlewareTest to
TabsSnapshotMapperTest, where they no longer need a store. The middleware's
remaining tests are driven through a real DefaultTabDataCoordinator over a
BrowserStore, so a test's reads and writes now share one source of truth; three
drag-and-drop assertions change to the tab order production actually produces,
which the previous static tab data flow could not observe.

Comment 3

[Noah Bond [:007]]

Attachment: Bug 2073219 - Part 3 - Migrate TabStorageMiddleware to use the coordinator for all tab data updates

The middleware now calls the coordinator, which owns both sources and applies, so the middleware keeps only what is genuinely Redux's: read the action, read the selection out of the store, and dispatch what the UI needs to know afterwards. It no longer holds the tab group repository, the move and remove use cases, or a date provider.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/9342426be293
https://hg.mozilla.org/integration/autoland/rev/f11f57314823
Part 1 - Add write APIs to Tab Data Coordinator r=android-reviewers,android-build-system-reviewers,RyanVM,jdelorenzo
https://github.com/mozilla-firefox/firefox/commit/35a34962e868
https://hg.mozilla.org/integration/autoland/rev/973a93dc3f52
Part 2 - Migrate the Tab Manager's tab data observations to the coordinator r=android-reviewers,jdelorenzo
https://github.com/mozilla-firefox/firefox/commit/f433b448e825
https://hg.mozilla.org/integration/autoland/rev/f2f6203f57d5
Part 3 - Migrate TabStorageMiddleware to use the coordinator for all tab data updates r=android-reviewers,jdelorenzo

Comment 5

[Noah Bond [:007]]

QA - this ticket involved a refactor of the underlying business logic for how tab data (not Sync) is passed into the tabs tray.

As part of the verification could we please verify the following functionality works as expected:

• Selecting tabs
• Re-arranging tabs
• Opening a new tab (normal/private)
• Opening a tab group
• Unlinking tabs from a tab group
• Opening a tab from within a tab group
• Marking a tab group as closed
• Re-opening a closed tab group from the tab groups page
• Closing a tab
• Closing a tab within a tab group
• Closing the last tab within a tab group
• Dragging a tab onto a tab to create a group
• Dragging a tab onto a group to add the tab to the group
• Dragging a group onto a tab to add the tab to the group AND move the group
• Dragging a group onto a group to merge the dragged group into the destination group.
• Updating a tab group's title
• Updating a tab group's color
• A tab with active media displays an icon over its thumbnail in the tab grid/list.

Comment 6

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/f11f57314823
https://hg.mozilla.org/mozilla-central/rev/973a93dc3f52
https://hg.mozilla.org/mozilla-central/rev/f2f6203f57d5