A recent change in Chromium is avoiding passing `PermissionRequestData`
as a unique_ptr around, and actually just as a ref where no mutate is
required.
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/173060c862de19ba0660a29697a1614782cd8c43
commit 173060c862de19ba0660a29697a1614782cd8c43
Author: Chris Fredrickson <cfredric@chromium.org>
Date: Wed May 14 07:23:01 2025 -0700
Avoid references to unique_ptrs in permissions API
A function that takes a reference does not typically care whether or not
the referent is allocated on the heap. So, the use of `const
std::unique_ptr<T>&` in the public API is unnecessary and overly
restrictive. (E.g., GeolocationPermissionContextDelegateAndroid can now
avoid an unnecessary heap allocation.)
Additionally, the const keyword only promises that the unique_ptr itself
is const; the referent might still be mutated. This is usually not the
desired behavior when using references, so this type is somewhat
misleading. (`const std::unique_ptr<const T>` would have to be used
instead, in order to get familiar "immutable argument" semantics.)
For both of those reasons, it is better to use a normal `const
PermissionRequestData&` instead of `const
std::unique_ptr<PermissionRequestData>&` in the public API.
Change-Id: Iae1228a7bf17f9de77a86e2e9c44592e6a418645
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6532217
Commit-Queue: Colin Blundell <blundell@chromium.org>
Reviewed-by: Florian Jacky <fjacky@chromium.org>
Commit-Queue: Chris Fredrickson <cfredric@chromium.org>
Auto-Submit: Chris Fredrickson <cfredric@chromium.org>
Reviewed-by: Colin Blundell <blundell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1460064}
This function was already gutted functionally, and now this
functionality is exclusive to ChromeOS.
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/4c52eb14ee5ad97ee65048fc7649ded426f7fa63
commit 4c52eb14ee5ad97ee65048fc7649ded426f7fa63
Author: Mikel Astiz <mastiz@chromium.org>
Date: Wed May 14 02:50:23 2025 -0700
[sync] Remove SetSyncFeatureRequested API
Gradually and definitely starting with the recent
https://crrev.com/c/6533710, SyncService::SetSyncFeatureRequested() did
nothing outside ChromeOS.
On ChromeOS, starting with https://crrev.com/c/6540467, there is a
better API to use in SyncUserSettings.
In this patch, ChromeOS callers are migrated to the better API and
everything else is cleaned up as they are no-op calls. As a result, the
SetSyncFeatureRequested API itself, as well as the Java counterpart, can
be safely deleted.
Bug: 40772592,40911173
Change-Id: I716ac1e59cc99afccf313697c0121858d19898c8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6540075
Commit-Queue: Mikel Astiz <mastiz@chromium.org>
Reviewed-by: Marc Treib <treib@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1459963}
The resource manager is now initialized in
`ChromeExtensionsBrowserClient::Init`, so we override that function in order to
make use of it.
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/efce54025758dc9d4f370c0269b332cb0d67474b
commit efce54025758dc9d4f370c0269b332cb0d67474b
Author: James Cook <jamescook@chromium.org>
Date: Mon May 12 13:00:22 2025 -0700
extensions: Use ChromeExtensionsBrowserClient on desktop Android, part 2
This makes desktop Android extensions behavior more like Windows,
Mac, and Linux.
Delete DesktopAndroidExtensionsBrowserClient. Extract the parts of
ChromeExtensionsBrowserClient that don't work on android to the file
chrome_extensions_browser_client_non_android.cc
Introduce an Init() method to UserScriptListener can be initialized
after g_browser_process creation (otherwise it crashes).
Fix a few small issues with ActivityLog initialization, prefs and
some extensions utility functions.
The CL is large, but most of it is cut-and-pasting functions from
chrome_extensions_browser_client.cc to _non_android.cc.
Bug: 415033270
Change-Id: Icfcca2a69b523ced6b5471ba659a1440a303a5c0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6509682
Reviewed-by: Yaron Friedman <yfriedman@chromium.org>
Commit-Queue: James Cook <jamescook@chromium.org>
Reviewed-by: Devlin Cronin <rdevlin.cronin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1459046}
`GetBraveServiceName` and `GetBraveAccountName` initialize and return a static
value based on a command-line flag. If these functions are called before the
command-line flag is set (as occurs now when running browser tests), then the
static value ends up initialized with the wrong service or account name.
Instead, we should use individual static variables to hold the values and return
the correct one at run-time.
`chrome/common/importer/importer_url_row.h` is now under `//components`.
This change corrects the inclusion header, as well as the deps for the
sources making use of this type.
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/92d2bd6e1e191227c779fcee6f26cf6a7f77740a
commit 92d2bd6e1e191227c779fcee6f26cf6a7f77740a
Author: Alexis Hetu <sugoi@chromium.org>
Date: Tue May 13 08:48:51 2025 -0700
Add //components/importer
We are working on adding data import functionality to //ios/chrome. To
facilitate reusing existing importation code, as well as possible
sharing/reuse of the new code we will be adding, we would like to add a
new components directory.
The use case here is for platform-independent logic relating to data
import, such as intermediary data structures, translation logic, and
interactions with other components-layer model objects (such as bookmark
storage).
This shared code is needed in multiple places in Chrome that couldn't
otherwise share code without this component:
* //ios/chrome
* //chrome/browser/importer
* //chrome/common/importer
* //chrome/utility/importer
As an example of the intended structure/how this component will be used,
I've moved one existing file from //chrome/common/importer into
//components/importer/core. This is a data structure we intend to reuse
verbatim, so it's a simple test case. As mentioned in the README, we
will also create a //components/importer/safari subdirectory, but that
code requires some nontrivial architecture discussions, so I elected not
to add that subdirectory in this initial CL.
See also design doc (sorry, Googlers only): go/bling-import
Change-Id: Iedbc1314935a9d098fb5f84ab37df186b5af082a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6505547
Reviewed-by: Colin Blundell <blundell@chromium.org>
Commit-Queue: Alexis Hétu <sugoi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1459474}
The local `record` was removed in the upstream code, however this value
is still needed for the override in this function.
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/7ac1151a4bc34535bf28ec7c3e48b132bcc0d96e
commit 7ac1151a4bc34535bf28ec7c3e48b132bcc0d96e
Author: Luis Pardo <lpardosixtos@microsoft.com>
Date: Tue May 13 08:49:47 2025 -0700
[source-phase-imports] Support Wasm Source Phase Imports
Adds ModuleRecord::ResolveSourceCallback to be called when instantiating
source phase children of the module graph.
Implement HostImportModuleWithPhaseDynamically and register it in the V8
isolate, this is called when executing `import.source`.
Add error handling for wasm imports in evaluation phase and non-wasm
imports in source phase.
Move module instantiation behind the ModuleScript interface to properly
throw evaluation phase errors.
Bug: 42204365
Change-Id: Ia3e855180f1f740023864b3499dc451278b53d47
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6351556
Reviewed-by: Dominic Farolino <dom@chromium.org>
Commit-Queue: Luis Pardo <lpardosixtos@microsoft.com>
Reviewed-by: Kouhei Ueno <kouhei@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1459475}
This change corrects the call for `SidePanelEntry` ctors, as the
argument list has slightly changed to take `Key`, and requiring default
values to be passed in.
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/a577a2710143e66a7d26894e79f6a9345461a91b
commit a577a2710143e66a7d26894e79f6a9345461a91b
Author: dljames <dljames@chromium.org>
Date: Tue May 13 09:34:35 2025 -0700
[SidePanel] Consolidate SidePanelEntry constructors
This CL consolidates the 2 different SidePanelEntry constructors into
one for convenience and the other being the primary constructor.
The reason there was 2 separate ones is because extensions doesn't use
any of the callbacks the larger constructor uses. Overtime this allowed
the constructors to diverge.
To consolidate we remove use of optional callbacks in the constructor
relying on callers to either provide an implementation or pass
base::NullCallback.
The extensions constructor is then converted into a convenience
constructor that is used for all entries that do not rely on the
additional callbacks.
Change-Id: Ic930e2d411338506a5e793f1ca6067c67185b25e
Bug: 416585199
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6528589
Reviewed-by: Caroline Rising <corising@chromium.org>
Commit-Queue: Darryl James <dljames@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1459508}
This change corrects several places to use modernised versions of
`SHA256Hash*`.
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/adc2dcebb5cc1de43f8b4ce958e50a39d9d1f4d1
commit adc2dcebb5cc1de43f8b4ce958e50a39d9d1f4d1
Author: Elly <ellyjones@chromium.org>
Date: Mon May 12 16:29:56 2025 -0700
crypto/sha2: remove truncating sha256
This change removes:
crypto::SHA256HashString(string_view, void*, size_t)
which accepted an output buffer as a raw void*. This function was
especially pernicious because passing a too-small buffer would result in
the hash being truncated, and passing a too-big buffer would result in
the part of the buffer after the hash being left uninitialized. Callers
that want this behavior now have to explicitly implement it themselves.
Change-Id: I395abeb48aef84fe49f35055a3dfb2ea6f2d1772
Bug: 372283556
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6534655
Reviewed-by: Matt Mueller <mattm@chromium.org>
Commit-Queue: Elly FJ <ellyjones@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1459152}
This change removes the checked out version of libm on our tree in
favour of the one checked into Chromium.
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/f65455728167d8f9424f44f65d9228d6c5d2a9eb
commit f65455728167d8f9424f44f65d9228d6c5d2a9eb
Author: Lukasz Anforowicz <lukasza@chromium.org>
Date: Fri Apr 25 11:51:16 2025 -0700
Roll libm: 0.2.11 => 0.2.13 in //third_party/rust.
This CL has been created semi-automatically. The expected review
process and other details can be found at
//tools/crates/create_update_cl.md
Updated crates:
* libm: 0.2.11 => 0.2.13
Bug: None
Change-Id: I402780caff6811f5cacdf889f651096cb43a0ef2
Cq-Include-Trybots: chromium/try:android-rust-arm32-rel
Cq-Include-Trybots: chromium/try:android-rust-arm64-dbg
Cq-Include-Trybots: chromium/try:android-rust-arm64-rel
Cq-Include-Trybots: chromium/try:linux-rust-x64-dbg
Cq-Include-Trybots: chromium/try:linux-rust-x64-rel
Cq-Include-Trybots: chromium/try:win-rust-x64-dbg
Cq-Include-Trybots: chromium/try:win-rust-x64-rel
Disable-Rts: True
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6479152
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1451956}
This change corrects a call to `OpenLinkInSplitView`, to use the local
function, rather than the class one. Upstream is introducing some sort
of split view, and this is running into issues with some of our
implementation.
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/544dc303da76db6e31aba8a58912cd5ff8df6e9f
commit 544dc303da76db6e31aba8a58912cd5ff8df6e9f
Author: Steven Luong <stluong@chromium.org>
Date: Thu May 8 14:29:36 2025 -0700
[SxS] Open link in split view via context menu
Right clicking a link should have an option to open that link in a new
split view with the active tab. If the active tab is already in a
split view, then the tab that isn't the source of the link should be
navigated to the link page.
Bug: 403351290
Change-Id: Icfda390b567d53dd52ca2d1731e070f164f2b7a5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6507814
Reviewed-by: Lei Zhang <thestig@chromium.org>
Reviewed-by: Teresa Mao <temao@chromium.org>
Commit-Queue: Steven Luong <stluong@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1457833}
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/5feda2b0095b0cce668eda789d9bff49aedaf585
[NTP Customization] Add NTP Customization toolbar button (part 3)
According to the NTP customization design, the visibility of the Home
button and the NTP customization button in the toolbar depends on the
homepage status. This CL adds an additional listener to the homepage
settings. While the original listener tracks whether the homepage is
enabled, the new listener checks whether the homepage is set to
something other than the NTP.
Bug: 407554279
Change-Id: Ic365520d658030cd953d1a65c4dafff451d5a67c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6517011
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/4e0c6f2ed20a06683a32e6ac271d29cdad5729e7
[Minimal UI] Disable minUI controls when secondary UI is shown
This CL has two parts, the first one changes back and reload buttons
contract - now instead of #setEnabled method they require to pass
an boolean ObservableSupplier that allows easier synchronization of
internal button state with external states, for example, dialogs overlay
while page is loading.
`setEnabled` API forces button to synchronize access internally by
managing access token, but as more controls will be added, more
tokens will be held in a parent. Instead a single token can be
managed by parent container, because individual enabled state is
a rare case and still can be added on top of the proposed API.
The second part adds ModalDialogManager into web app header.
Header listens to shown dialogs and enables/disables controls when
ovelaid with any. As soon as dialog queue is drained, controls will be
enabled back.
Bug: 412910949
Change-Id: Ice3ee83637d9a88c4c2c84dd4fd167a3ebe8b82b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6499077
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/c59eeff40f493459618031de68c3abdc932d1d8d
Reland "[Android] Support multi-window in Public Transit tests"
This is a reland of commit 9527df220a190af84652625ff34f44ea0ad927e4
Changed: Restricted test to non-Auto as it does not support
multi-window.
Bug: 414438679,415935250
Change-Id: I368b5a5f260050c2c4e200df0aa93c99c4687991
Original change's description:
> [Android] Support multi-window in Public Transit tests
>
> - TrafficControl now accepts 0+ Stations as active instead of 0-1.
> - ActivityElement waits for an Activity in the same window or on a
> different one, depending on the transition (or any window in the
> first transition.
> - Station now has #spawnSync to transition into a Station in a new
> Window without leaving the current Station in the existing Window.
> - Add MultiwindowAppMenuTest using all of this to test the 'New
> Window' menu item in Tablets.
>
> Bug: 414438679
> Change-Id: If963b5d3bb845eb8a71e22c448b2687b71eeffc7
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6488661
> Commit-Queue: Henrique Nakashima <hnakashima@chromium.org>
> Reviewed-by: Aishwarya Rajesh <aishwaryarj@google.com>
> Owners-Override: Henrique Nakashima <hnakashima@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1455965}
Change-Id: I368b5a5f260050c2c4e200df0aa93c99c4687991
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6513365
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/55bc1473c10ac7470c2c2133d26d69c936bdc502
[Minimal UI] Add ThemeColorProvider for browser services
Adding a new ThemeColorProvider that targets browser services
primary color calculations based on the web app manifest and
Chrome default theme. It doesn't add anything new in color calculations
themselves, but rather extracts existing logic from
CustomTabColorController to share with other UI controls like web app
header.
Focused/unfocused primary color will be implemented in scope of
another task.
Bug: 396101424
Change-Id: I2ee3712725e9e1069a1e30c9dccbd33a4af8ce1b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6487756
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/73a146fefe836a891e3164c37f90f4ccf9ea776d
commit 73a146fefe836a891e3164c37f90f4ccf9ea776d
Author: Alison Gale <agale@chromium.org>
Date: Wed May 7 09:58:55 2025 -0700
[SxS] Refactor logic for checking if bookmark bar should show
For split tabs, we will need this logic to include looking at both
halves of a split. To do that, it would be helpful if this were a util
rather than a tab helper since it won't just be looking at one tab. This
CL does not change any existing functionality, it just moves code.
Bug: 415071206
Change-Id: Ib5d073f63f485a9d3c26895a7be186cc4c49db09
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6513970
Commit-Queue: Alison Gale <agale@chromium.org>
Reviewed-by: Eshwar Stalin <estalin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1457075}
This change corrects several places where `SetCornerRadius` is not
available anymore to some equivalent of a rounded corners function.
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/34c4b0e9ebd7a0681413aef552217ca88701afc5
commit 34c4b0e9ebd7a0681413aef552217ca88701afc5
Author: Zoraiz Naeem <zoraiznaeem@chromium.org>
Date: Wed May 7 10:59:27 2025 -0700
Support variable rounded corners for BubbleBorder and BubbleFrameView
BubbleBorder currently supports variable corner radii using an
additional setter, an API implemented for ash HelpBubbles
(crrev.com/c/4523373).
However, simply painting a rounded BubbleBorder does not create a fully
rounded bubble. The BubbleFrameView also needs to be rounded. This
change introduces variable rounded corner support to BubbleFrameView and
unifies the BubbleBorder API.
Bug: b:416034720
Change-Id: Iaff284b2c5df180af4ab1cff91fba579ac7e902e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6504935
Reviewed-by: Elly FJ <ellyjones@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Commit-Queue: Zoraiz Naeem <zoraiznaeem@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1457124}
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/f311255639083a1716f4d76cd4febd23578caf77
commit f311255639083a1716f4d76cd4febd23578caf77
Author: Zoraiz Naeem <zoraiznaeem@chromium.org>
Date: Wed May 7 13:32:23 2025 -0700
Manual re-land of crrev.com/c/6314413
This CL also update implementation of `set_background_color()`.
Previously, it only modified the member variable, and the frame color
was updated during widget initialization or theme changes. Now,
`SetBackgroundColor()` directly updates the frame color when feasible.
This change is necessary because some implementations of
BubbleDialogDelegate change bubble's background color outside of widget
initialization and theme changes.
Bug: b:412578829
Change-Id: I2366e754891d58f9a222f255c32b339ced212bfe
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6512100
Reviewed-by: Elly FJ <ellyjones@chromium.org>
Commit-Queue: Zoraiz Naeem <zoraiznaeem@chromium.org>
Reviewed-by: David Pennington <dpenning@chromium.org>
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1457237}
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/30974a8a2b9b0ecdea5c944ae4c85053e5d6cbcd
commit 30974a8a2b9b0ecdea5c944ae4c85053e5d6cbcd
Author: Zaina Al-Mashni <zalmashni@google.com>
Date: Tue May 6 11:21:04 2025 -0700
[Settings] Convert the DataType checkboxes to an expandable list in DBD
This change does the following:
- Converts the checkboxes in the DBD settings page from a static list
to an expandable one.
- Default (History, cache and site data) and selected datatypes are
always visible in the expandedOptions list.
- Others datatypes are hidden until the user clicks on show more in the moreOptions list.
- The two lists do not change after the page is created and maintain the same order.
Demo (WAI - checkboxes unchanged):
NO_IFTTT=This is the initial addition for the LINT.IfChange/ThenChange.
Demo: https://drive.google.com/file/d/19A2L4DO3EXRYBx24WOBVdwnSPQySRbUR/
https: //drive.google.com/file/d/1eKPy9agH47D4Yxrv6BgBQuzRoA9VtY0s/
Bug: 397187800
Change-Id: Ib8ae012d4c536ec004d535ffb3217797462850f0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6490751
Reviewed-by: Rainhard Findling <rainhard@chromium.org>
Reviewed-by: Christian Dullweber <dullweber@chromium.org>
Commit-Queue: Zaina Al-Mashni <zalmashni@google.com>
Reviewed-by: John Lee <johntlee@chromium.org>
Auto-Submit: Zaina Al-Mashni <zalmashni@google.com>
Commit-Queue: John Lee <johntlee@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1456473}
This is necessary as the extension is done in the mojom file.
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/ee99ed9c7dc2b054a3fbedaa611925eb9b52f240
commit ee99ed9c7dc2b054a3fbedaa611925eb9b52f240
Author: Wojciech Dzierżanowski <wdzierzanowski@opera.com>
Date: Thu Apr 17 05:42:20 2025 -0700
Surface MediaMetadataChanged() and use it in TabStatsTracker
This empowers WebContentsObservers to observe changes in the set of
tracks in a media player.
TabStatsTracker wasn't aware of changes in the set of tracks. Thus, it
missed events such as adding or removing a video track, which from its
point of view are equivalent to starting and stopping video playback.
By overriding MediaMetadataChanged(), TabStatsTracker can properly
detect video track additions and deletions. At the same time, we
centralize the logic of counting video players in
MediaWebContentsObserver, thus avoiding duplication of responsibility.
Bug: 383513678
Change-Id: Idce01394af5b1cc1b2e9321f0c6cde955aac2cc7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6091036
Reviewed-by: Camille Lamy <clamy@chromium.org>
Commit-Queue: Wojciech Dzierżanowski <wdzierzanowski@opera.com>
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: Francois Pierre Doray <fdoray@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1448254}
chrome://about is now implemented as a new lit-based WebUI. We now use our Lit
mangler to perform the necessary chrome: -> brave: scheme replacements. This
only affects the display of the URL schemes, not the underlying schemes
themselves.
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/6448145f55afaf3f259f5c30f82c39aeb5f0f6ef
commit 6448145f55afaf3f259f5c30f82c39aeb5f0f6ef
Author: Sylvain Defresne <sdefresne@chromium.org>
Date: Tue May 6 11:14:20 2025 -0700
[ios] Disable chrome://newtab links in chrome://chrome-urls
There is no WebUI handler installed for chrome://newtab, so the
link cannot be handled. Thus change chrome://chrome-urls to that
the chrome://newtab is not tappable.
Fixed: 415753154
Change-Id: I108b58d905e780f88dbe948f81b4a8ffc0a9eecf
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6513048
Commit-Queue: Sylvain Defresne <sdefresne@chromium.org>
Auto-Submit: Sylvain Defresne <sdefresne@chromium.org>
Reviewed-by: Asami Doi <asamidoi@chromium.org>
Commit-Queue: Asami Doi <asamidoi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1456462}
This flag is now gone, so we disable this feature at the same points where the
flag used to be checked.
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/7249485e604c9ea69efcd7f7635d5edd2f4fdcbb
commit 7249485e604c9ea69efcd7f7635d5edd2f4fdcbb
Author: Ari Chivukula <arichiv@chromium.org>
Date: Wed Apr 30 09:11:08 2025 -0700
Clean up stale base::Feature "UsePopularSitesSuggestions"
It looks like this experiment is over and/or launched so the code can be
cleaned up.
Fixed: 356236774
Now that the transition to the Rust implementation of `JSONReader` is complete,
`base::JSONReader::UsingRust` has been removed.
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/5077893a42eebf665680b8fbe8731be3e686eab8
commit 5077893a42eebf665680b8fbe8731be3e686eab8
Author: Daniel Cheng <dcheng@chromium.org>
Date: Fri May 2 14:34:10 2025 -0700
Reland "Clean up kUseRustJsonParser"
This is a reland of commit fc3436425ec94c94052e1449dda2061beab23785
The original CL was reverted due to a cast-specific shared library
depending on //base and inadvertently introducing two copies of //base
when loaded into another process that already had symbols for //base.
That shared library no longer depends on //base.
Original change's description:
> Clean up kUseRustJsonParser
>
> Bug: 404881580
> Change-Id: I9e3533b3fdbf436ab37917efbe3cbaf9e7091f67
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6492579
> Reviewed-by: Reilly Grant <reillyg@chromium.org>
> Owners-Override: Lei Zhang <thestig@chromium.org>
> Reviewed-by: Lei Zhang <thestig@chromium.org>
> Commit-Queue: Daniel Cheng <dcheng@chromium.org>
> Reviewed-by: Maks Orlovich <morlovich@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1454226}
Bug: 404881580
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/be55153df12fd44a855f9db49f4656e624db3010
commit be55153df12fd44a855f9db49f4656e624db3010
Author: Takashi Toyoshima <toyoshim@chromium.org>
Date: Fri May 2 11:13:52 2025 -0700
Reland "NavigationThrottleRunner2: content::NavigationThrottleRegistry"
This is a reland of commit 06e076907244efc5fae5abe219b326238889071d
The original change below didn't handle a chromecast specific subclass,
and it caused a build failure on chromecast bot.
Original change's description:
> NavigationThrottleRunner2: content::NavigationThrottleRegistry
>
> This CL introduces a NavigationThrottleRegistry.
> CreateThrottlesForNavigation() is changed to use this interface to
> register a NavigationThrottle for a new navigation.
>
> We still handle the returned throttles vector to keep the legacy
> interface available. But, once all the existing NavigationThrottle are
> migrated to use the NavigationThrottleRegistry, we will remove the
> legacy way, and the signature will be changed to return void.
>
> With this interface, we can implement several optimization step by step
> without changing the existing API signature further more. For instance,
> we can provide following features via the new registry interface;
> - fast access paths to check navigation attributes
> - per-event registration to optimize event loops
>
> Eventually, I will introduce a new NavigationThrottleRunner class. As we
> want to share some common implementation among the original runner and
> the new runner during the experiment, I will move the common logic to
> this registry class and both runners will own it to share the
> implementation.
>
> Essential changes are in the NavigationThrottleRunner, and
> //content/public. Others are call side mechanical changes.
>
> Bug: 412524375
> Change-Id: Ifda11e0f5cf446135c9ab34df025573346c7639c
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6478853
> Reviewed-by: Nate Fischer <ntfschr@chromium.org>
> Auto-Submit: Takashi Toyoshima <toyoshim@chromium.org>
> Commit-Queue: Takashi Toyoshima <toyoshim@chromium.org>
> Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1454542}
Bug: 412524375
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/8c1fa87a4abe37ec7aba186a7c857b431ffd36ae
commit 8c1fa87a4abe37ec7aba186a7c857b431ffd36ae
Author: Michelle Abreo <michelleabreo@google.com>
Date: Mon May 5 10:24:21 2025 -0700
Update OnStatusChanged API with CookieControlsState enum.
The following CL will update the toggle logic to take a
CookieControlsState parameter instead of a boolean for "protections_on"
/ "is_on" / "is_toggled" so that we are just passing one value that can
be used for both regular mode and incognito mode.
Will update the OnCookieControlsIconStatusChanged API in a separate CL.
go/act-page-info-ui-1p
Bug: b:388294499
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/84855d0b8ea6c2d2836a8885ba254d2f2928f770
commit 84855d0b8ea6c2d2836a8885ba254d2f2928f770
Author: manukh <manukh@chromium.org>
Date: Wed Apr 30 18:56:41 2025 -0700
[omnibox] Use enum param for `Stop()`
go/autocomplete-controller-refactor-phase-2
Currently, `AutocompleteController::Stop()` &
`AutocompleteProivder::Stop()` have 2 bool params:
1) `clear_cached_results` - whether the controller's `internal_result_`
and providers' `matches_` should be cleared.
2) `due_to_user_inactivity` - whether `Stop()` was triggered by the
controller's `stop_timer_` or user interaction. This affects what
providers respect or ignore the `Stop()` request. (I'm not sure what
this was used for before we had providers that were allowed to ignore
the `Stop()` requests).
This CL replaces the 2 bool params with a verbose enum `StopStrategy`.
- `Stop(kMustStopAndClearMatches)` is equivalent to `Stop(true, false)`
- `Stop(kMustStopAndKeepMatches)` is equivalent to `Stop(false, false)`
- `Stop(kMaybeStopAndKeepMatches)` is equivalent to `Stop(false, true)`
The benefits of using an enum are:
- `Stop(true, true)` was not a valid param combination, but there was no
way for a dev to know this.
- `Stop(bool, bool)` doesn't communicate how these params affect the
stop behavior or what values should be used.
The above has no behavior changes.
Other notes:
- A few providers' `Stop()` ignored `clear_cached_results = true` and
will continue to ignore `kMustStopAndClearMatches`. I didn't dig into
whether these could be updated to actually clear their `matches_`
without breaking behavior; but skipping the clear seems
non-problematic. Might revisit in a followup CL consolidating the
`Stop()` implementations.
- Calculator provider was one such provider, which this CL does update
to not ignore the clear request because I know that is definitely
non-problematic.
- Some provider `Start()` methods call `Stop(/*clear=*/ true)`; others
call `Stop(/*clear=*/ false)`; others call `Stop(/*clear=*/
!minimal_changes)`; others don't call `Stop()`. All cases are valid,
and some of these calls (or lack of) might be intentional; but most
are likely unintentionally written following some other provider's
example. It'd be nice if we could have the base class method
`AutocompleteProvider::Start()` handle whether to call `Stop()` and
with what param for all providers. Might revisit in a followup.
- Likewise, most provider `Stop()` methods call the base class
`AutocompleteProvider::Stop()`, but a few don't. Again, both of these
are valid, and at least 1 case of not calling `AP::Stop()` is
intentional; but it'd be nice if we could centralize this to make sure
none are oversights. Very likely will revisit in a followup.
Change-Id: Ibc5a21eef1de8fc4dc2fe9b021cf6c369fb1f3c0
PermissionRequestData is now used to pass various permission parameters around
and several functions/constructors were modified to accomodate that change.
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/7f3e3ca1b6ceddc2e18a4fe86d2ce3ac936e68ba
commit 7f3e3ca1b6ceddc2e18a4fe86d2ce3ac936e68ba
Author: Florian Jacky <fjacky@google.com>
Date: Mon May 5 09:19:20 2025 -0700
[PermissionOptions] Simplify request path, provide resolvers, pass back request information
This CL is part of a larger change to support permissions with options. A summary of changes in this CL can be found below, the full de>
- Simplify interfaces to rely on PermissionRequestData wrapper and refactor PermissionContextBase and its subclasses accordingly.
- Update PermissionRequestData to rely on permission resolvers.
- Refactor PermissionRequest to rely on unique PermissionRequestData object and pass it to permission decided callbacks. Let Permission>
Full design doc: http://go/multi-state-permissions-dd
Change-Id: I81df3cbcedb9c7ef2340a0d79734adf77f336aae
Bug: 394547183, 393053278
Claudio DeSouza
