At this moment, we have two extension methods that have duplicate
functionality to construct search term groupings. One on `List<Tab>` and
one on `List<TabSessionState>`. The former is used for everything
related to tabs piped through the `TabsFeature` and the latter is for
consumers of `BrowserState` directly.
The bug occurs because our implementation of search groupings was
updated only on the former extension, but the `HeaderBinding`, that
observes the BrowserState and updates the title visibility, was using
the latter.
Ideally, we remove this duplication when we no longer have separate data
classes for consumers of `TabsFeature`, but this intermediary fix should
suffice.
Before this patch, this was the behavior - 'remove' button is clicked, we'd ask
the storage to remove metadata (on its IO thread), then navigate to Home
Screen.
This resulted in a race we could end-up on the Home Screen before delete
finishes, so the search groups do not appear to be removed (but,
refreshing the Home Screen again shows that they are removed).
This also resulted in an unnecessary navigation which felt very janky
(screen will "scroll" to the top) and was way more work than necessary.
After this patch, we:
- dispatch two actions (on browserstore, on homefragmentstore) which
remove the search groups from any relevant in-memory state; any UI bound to
this state will be automatically "refreshed"
- no longer navigate as part of the remove action, so the UI doesn't
move and removal happens "in-place"
It seems like we no longer need to use rotation for the chevron, since
we are now using two different icons within the `ic_chevon` that change
depending on the `state_activated`.
This helps identify file IO. Unfortunately, with this marker, it's
difficult to separate code we own from code we don't own. However, I
wasn't sure what the best implementation would be to address that
(e.g. ideally, we would ignore violations in code we don't own rather than
annotate the markers) so I thought we can land it this simple way and
improve it incrementally.
* For #21437 - Relocated Home-related settings to its dedicated sub screen
* For #21437 - Updated show top sites toggle text
* PR: Fixed lint warning. Reverted preference keys
* PR: added ignore for UI test
* PR: Added ignore for UI test
The bottom gray border of the header item from the Inactive Tabs section was correctly set when collapsing or expanding said section, but not on init. So if the section was initialized collapsed the gray border would not be present.
This regressed in our previous fix that made sure child tabs don't
mistakenly get moved out of the group if their parent is navigated
away, or in case the child tabs are redirected.
However, when a subsequent load occurs in any tab in the group the
search terms need to be cleared and the tab removed from the group
to prevent false positives.