* Upgrade from Chromium 123.0.6312.29 to Chromium 123.0.6312.46
* Update pins list timestamp
* Updated strings for Chromium 123.0.6312.46
* [Android] Fix omnibox gap on automotive portrait devices
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/2dd3c04e44bed5cc554d93dac98f05d597cce7cd
[Merge into M123] Fix omnibox gap on automotive portrait devices by measuring from below the automotive top toolbar
(cherry picked from commit 5a1c036eff85c1664daefabe9261bb897476c932)
Bug: b/327277287
---------
Co-authored-by: brave-builds <brave-builds+devops@brave.com>
Co-authored-by: Artem Samoilenko <artem@brave.com>
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/4dfe0238c9391e5b9a4284072e7d07926171215b
[Tab Groups] add Token-based ID support behind flag
Add and manage Token-based TabGroupIds for Tabs in TabGroupModelFilter.
RootId must be the TabId of one of the tabs in the group. This is
unstable because if the Tab with the TabId corresponding to the RootId
of the group is removed from the group the group must elect a new
TabId from among its tabs to be the new RootId. This leads to issues
with managing the state of a tab group over time.
Under the RootId paradigm every tab was associated with a TabGroup
object and only tab groups with > 1 tab were considered "real" tab
groups. In an effort to support tab groups with a single tab it is
necessary to come up with a new approach.
This CL introduces TabGroupId. This ID is stable in that it is tied
to the group the tabs are in and can only be destroyed if all tabs
are removed from the tab group OR two groups with TabGroupIds are
merged resulting in one of the two TabGroupIds going away.
Tabs only have a TabGroupId if they are associated with a "real"
tab group of size 1 or larger. Otherwise this field will be null.
This means that TabGroup objects will only contain tabs with a
TabGroupId if the group is > size 1 OR that single tab is to be
treated as a real tab group.
If the flag AndroidTabGroupStableIds is enabled then after
tab state initialization all tabs that are part of "real" tab
groups under the old definition will be allocated TabGroupIds
in a 1:1 manner with old RootIds. When the flag is disabled
the TabGroupIds will all be reset instead.
Logic for maintaining TabGroupIds is as follows:
* A Tab Group Id is allocated when:
* A single tab is turned into a single tab group.
* A single tab is merged with another single tab to form a
group.
* A list of tabs is merged to a single tab to form a group.
If a group is merged to a single tab its Tab Group Id is
preserved.
* Tab Group Ids are removed from tabs when:
* Ungrouping a tab from a group.
* Tab Group Ids are lost entirely when:
* Merging two tab groups both with tab group ids (only one ID will
continue to exist).
* Removing the last tab from a group.
* Deleting an entire tab group.
Bug: b/41496693
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/844b35bf460b339650d488d005935f802543cd0f
[MagicStack] ModuleRegistry shouldn't be a singleton class.
In this CL:
1) ModuleRegistry is created by ChromeTabbedActivity, and is
plumbed to magic stack. This allows one ModuleRegistry per
ChromeActivity, and is safe to register builder instances based on
the ChromeActivity's data, like TabModel. A refactor is done to
plumb the ModuleRegistry instance to Start surface | NTP.
2) Move some static APIs from ModuleRegistry to singleton class
HomeModulesConfigManager. It allows HomeModulesConfigSettings to
access the set of configurable modules.
3) Replace ModuleProviderBuilder#isEligible() with a new
ModuleConfigChecker interface. It allows the details remain in each
module builder.
Bug: b/324312039
Deep Pandya