Chromium change:
https://source.chromium.org/chromium/chromium/src/+/ca92a829fd33027f91e5098c25451a782a44ba8f
commit ca92a829fd33027f91e5098c25451a782a44ba8f
Author: Takuto Ikuta <tikuta@chromium.org>
Date: Mon Apr 20 19:18:33 2026 -0700
build: refine symbol_level and use_debug_fission in compiler.gni
This change moves the declaration of symbol_level earlier to allow its
use in the default value of use_debug_fission. It also ensures that
use_debug_fission is only enabled when symbol_level is at least 1, and
adds an assertion to enforce this.
Bug: 502431091
ObliviousHttpResponse headers field cannot be skipped because it's not a
nullable field and the upstream change below now validates fields.
The header value is not important since we don't check it in the test.
Chromium change:
https://chromium.googlesource.com/chromium/src.git/+/d8255385dd669
commit d8255385dd669a6580e605b8d9b04a86ed91b5c9
Author: Daniel Cheng <dcheng@chromium.org>
Date: Tue Apr 14 19:18:52 2026 -0700
Reland "Remove use deprecated [Native] types in network_param.mojom"
This is a reland of commit c565345fc495c824f8a1c54f11461dbfaf235551
The only additional fix is to mark HTTPResponseHeaders as nullable in
NetworkService::ParseHeaders().
Original change's description:
> Remove use deprecated [Native] types in network_param.mojom
>
> This ends up being large change since it is easiest to convert an entire
> tree of `[Native]` types at once, as it's a awkward to mix and match
> `[Native]` and non-`[Native]` types without introducing temporary
> `[Native]` types to bridge the transition. The opaque nature of
> `[Native]` types also means that there were types that Mojo didn't even
> know about at all, further increasing the size of the change.
>
> To avoid making network_param.mojom a dumping ground of arbitrary types,
> define the new types in distinct .mojom files, using a simple heuristic:
> if the C++ types are defined in a single header, the Mojo types should
> be defined in a single .mojom file as well. Several types previously
> defined in network_param.mojom are also moved out to match this
> heuristic.
>
> The typemap definitions are also reorganized and split into smaller
> blocks; in theory, this should allow more granular dependencies, though
> this CL does not take full advantage of this since all the trait
> definitions are built as one source set still. Additional cleanups:
> - normalize how .cc trait sources are defined in the GN rules–the
> typemap definitions no longer use `trait_sources` and depend on the
> `source_set` that includes all the trait sources
> - normalize where trait declarations and definitions live: the traits
> for X509Certificate are now in x509_certificate_mojom_traits.{cc,h}
> rather than being split across x509_certificate_mojom_traits.h and
> network_param_mojom_traits.cc.
>
> Many typemaps also need to become shared typemaps now. This is necessary
> because `URLLoaderCompletionStatus` transitively depends on `SSLInfo`,
> which was previously a `[Native]` type. Unfortunately, this results in a
> large compile size increase which is unavoidable: `[Native]` types are
> entirely opaque to Mojo and as such, very little generated code was
> needed to support them. Teaching Mojo about these types results in a lot
> more generated code.
>
> `HttpResponseHeaders` now has an internal, shared serialization helper,
> since serializing to a pickle first and then serializing to Mojo is an
> additional wasted copy. This helper is used by the original `Persist()`
> method, as well as the new `SerializeForMojoIpc()` method. It would be
> possible to do even better here, i.e. by teaching Mojo how to serialize
> a segmented string, but that is left for a future followup if additional
> efficiency is needed.
>
> Since `HttpResponseHeaders` and `X509Certificate` are no longer opaque
> types, nullability checks are now enforced by Mojo deserialization: this
> revealed several bugs (in `CertVerifierService`, `NetworkContext`, and
> `URLResponseHead`) where fields/parameters are not marked as nullable
> despite comments indicating it could be null.
>
> Finally, though it's not strictly necessary, make `HttpResponseHeaders`
> a shared typemap as well. The raw form of `HttpResponseHeaders` is hard
> to hold correctly, and it's safer to use the `net::HttpResponseHeaders`
> to handle it.
>
> Bug: 393179188
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/009a939161f47dd44355fd1d583360437f028d53
commit 009a939161f47dd44355fd1d583360437f028d53
Author: Rusty Sammon <sammon@google.com>
Date: Wed Apr 29 07:36:25 2026 -0700
Support per-command encryption in CommandStorageBackend.
New file format v5 is similar to file format v4, which was deleted in
crrev.com/c/7551490. The main difference is that v5 uses OSCryptAsync to
perform the encryption.
Update SessionCommand to support encryption.
BUG=479420496
This feature has been broken in brave, and because of that it was
disabled before with a build flag. In M149 that build flag doesn't
produce a coherent build anymore, so we fall back to overriding the
feature flag.
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/dd6626cdd58e0ccd306599507de9a47e5a2573e9
commit dd6626cdd58e0ccd306599507de9a47e5a2573e9
Author: April Kallmeyer <ask@chromium.org>
Date: Fri Apr 24 15:25:16 2026 -0700
[PDF Ink Signatures] Call the new pdfViewerPrivate.getTextInfo() API
Pass the results of getTextInfo() to the backend on text annotation
commit and cache which fonts were already loaded.
Ink2Manager keeps track of the IDs previously sent and will not
repeatedly send the same font data to the backend to load, and it will
tell the getTextInfo() private API not to serialize the known fonts. The
backend is expected to save and reuse the font data from the frontend.
Bug: 408976049
Co-Authored-By: Lei Zhang <thestig@chromium.org>
Change-Id: Ifcfd99dcae3d05f5ce5d49f81130ccb9f0cdb731
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7728778
Commit-Queue: April Kallmeyer <ask@chromium.org>
Reviewed-by: Demetrios Papadopoulos <dpapad@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1620509}
Removes the `NOTREACHED` in `-[CWVWebViewConfiguration preferences]` that is hit in some new `CWVWebView` code, the `NOTREACHED` was originally to avoid developer error in accessing it from Swift, but we can instead just mark it as unavailable with `NS_UNAVAILABLE` to avoid that possibility instead and allow the Obj-C side to just coalesce on null.
Chromium change:
commit 29b0e7808c42609ad6a816161d65acc6d2b46841
Author: Anuj Kumar <anujbh@google.com>
Date: Fri Apr 17 15:27:16 2026 -0700
[ios/web_view] Add triggerNonFatalCheck to CWVPreferences
Adds a new non-persistent, in-memory property 'triggerNonFatalCheck'
to CWVPreferences. When enabled, it triggers a non-fatal CHECK during
CWVWebView initialization to facilitate integration testing of
non-fatal checks by CWV clients.
Note: All code added in this CL is temporary for release integration
testing and will be reverted after testing in the stable channel
concludes.
The CHECK is implemented as:
CHECK(false, base::NotFatalUntil::M235); with a distant launch
milestone to ensure cleanup occurs before it becomes fatal.
Bug: 503005516
Change-Id: Ifea699ed37f2760bcc80cc49a71968075c2ad148
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7751665
Reviewed-by: Justin Cohen <justincohen@google.com>
Commit-Queue: Anuj Kumar <anujbh@google.com>
Reviewed-by: John Wu <jzw@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1616907}
commit f870b7893adc664604830556d59f4e5c615805f1
Author: Daniel White <danieltwhite@google.com>
Date: Fri Apr 10 07:24:27 2026 -0700
[iOS] Bumping the minimum deployment target to iOS 18
In this CL, the minimum version a user needs to be running to use the
application was raised to iOS 18.
Bug: 469423473
Change-Id: I0caa6d7e8b332411144355ff7b8980f0fa155caf
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7559054
Reviewed-by: Rohit Rao <rohitrao@chromium.org>
Commit-Queue: Daniel White <danieltwhite@google.com>
Cr-Commit-Position: refs/heads/main@{#1612847}
In both upstream and our tests.
These tests crash on exit because of the stale pointer to GCMDriver held
by FCMHandler in SyncInvalidationsService. The pointer is stale because
the upstream change swaps the GCMProfile service to a fake one after the
SyncInvalidationsService initialization.
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/23f0c1d6
commit 23f0c1d6b721719bd1e9e220dc3e85cca23e048b
Author: Justin Lulejian <jlulejian@chromium.org>
Date: Mon Apr 27 19:02:39 2026 -0700
[Extensions] Connect userVisibleOnly pref to renderer queries
Before this commit, the `userVisibleOnly` push subscription option was
hardcoded to true when reported to the renderer, even though it was
persisted in preferences. This prevented the renderer from knowing if a
subscription was silent when calling `getSubscription()`. For example if
an extension that passed `userVisibleOnly : false ` called this:
```
background.js
const subscription = await registration.pushManager.getSubscription();
console.assert(subscription.options.userVisibleOnly);
```
It would never assert (since `userVisibleOnly` was always forced to
`true` in `PushMessagingManager::GetSubscriptionDidGetInfo()`).
After this commit, the pref is now piped correctly piped from //chrome/
(read from prefs) to //content/ (requested by renderer). Now
`subscription.options.userVisibleOnly` will correctly report the push
subscription's `userVisibleOnly` value.
This was accomplished by updating `SubscriptionInfoCallback` to include
`user_visible_only`, updating `PushMessagingServiceImpl` to extract it
from `AppIdentifier` and pass it through callbacks, and updating
`PushMessagingManager` to receive and use it.
There are two tests to cover this.
ExtensionsPushMessagingServiceTest.GetSubscriptionPersistsUserVisibleOnlyFalse
is a unit test that the value is correctly reported.
ServiceWorkerPushMessagingTest.GetSubscriptionPersistsUserVisibleOnlyFalse
is an e2e test where an extension worker verifies that its
`subscription.options.userVisibleOnly` returns expectedly false.
Fixed: 391114807
Change-Id: Ib4767f3bc00a402e1a6748241196370c36f08a0c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7784893
Reviewed-by: Andrea Orru <andreaorru@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Auto-Submit: Justin Lulejian <jlulejian@chromium.org>
Reviewed-by: Zijie He <zijiehe@google.com>
Commit-Queue: Justin Lulejian <jlulejian@chromium.org>
Reviewed-by: Michael van Ouwerkerk <mvanouwerkerk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1621487}
Upstream's `webView:startURLSchemeTask:` now rejects any WebUI sub-resource
whose `SchemeHostPort` differs from the main `webView.URL` unless it is
served from `chrome://resources`. That breaks Brave's per-frame `WebUIIOS`
support (04db68e84d), where a trusted WebUI page deliberately embeds a
chrome-untrusted (or sibling-host) WebUI iframe (e.g. AI Chat).
Extend the existing chromium_src override to also admit any URL recognized
by a registered `WebUIIOSControllerFactory`. Non-WebUI URLs continue to
fall through to the upstream check, preserving its hardening intent.
Fixes the `WebUITest.LoadWebUIPageWithWebUIChildFrame` integration test.
Note: AI-assisted: requires thorough review
Chromium changes:
https://source.chromium.org/chromium/chromium/src/+/6b67808f449e4e6ebfd00182dcf09c7a37bb75b9
commit 6b67808f449e4e6ebfd00182dcf09c7a37bb75b9
Author: Mike Dougherty <michaeldo@chromium.org>
Date: Mon Apr 27 02:18:09 2026 -0700
Correctly pass WebUI headers to resource response
This CL forwards headers set on URLRequestChromeJob instances inside
URLDataManagerIOSBackend to the actual response. Previously these
headers were unintentionally discarded.
Although set_add_content_security_policy is being explicitly disabled in
this CL, it represents no change in behavior because the header was not
previously forwarded to the response.
Bug: 502503860
Change-Id: I85b33794a405bf132b094c47e890df0473c1b591
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7764734
Auto-Submit: Mike Dougherty <michaeldo@chromium.org>
Commit-Queue: Gauthier Ambard <gambard@chromium.org>
Reviewed-by: Gauthier Ambard <gambard@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1620954}
Fix test failures in `BraveBrowserViewWithRoundedCornersTest` test suite.
After the upstream consolidation onto a single toolbar-height side panel, our
rounded-corners code still operated on the V1 sidebar_container's internal
panel, leaving the upstream `BrowserView::side_panel_` (the panel actually
toggled by `SidePanelCoordinator` and asserted on by tests) without margins,
border, or shadow. This change applies `kMarginsKey` and `UpdateBorder()` to the
upstream panel in V1 mode (the V1 internal panel keeps its existing metadata for
`sidebar_container` layout). It also overrides
`BrowserViewTabbedLayoutImpl::ShadowOverlayVisible()` to return false so the
upstream shadow overlay's `kSidePanelInset` padding doesn't double up with
Brave's own rounded-corners shadow.
Note: AI-assisted: requires thorough review
`metricsReportingControl` was moved behind a template, so adjust our override to
continue hiding it.
Since this file was small, also took the opportunity to address all of the "long
line" presubmit warnings by reformatting it.
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/bd6340f42957d39006ef61602100b801cb56ef48
commit bd6340f42957d39006ef61602100b801cb56ef48
Author: Chirag Arora <heychirag@google.com>
Date: Thu Apr 30 01:48:06 2026 -0700
Hide "Help improve Chrome ..." toggle on Desktop and link on ChromeOS
This change hides the usage and crash reporting setting in the
personalization options page when the metrics consent restructure
is enabled and the user has been migrated to the new consent settings.
The implementation varies by platform:
- On Desktop, the #metricsReportingControl toggle is hidden.
- On ChromeOS, the #metricsReportingLink link row is hidden.
Tests were added to both metrics_reporting_test.ts (for Desktop) and
personalization_options_test.ts (for ChromeOS) to verify the behavior
on each platform.
Bug: b:496476603
Change-Id: Ie23879c2ef4d8cc0760d3d81cce9059095fed2a5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7790348
Reviewed-by: Mike Wasserman <msw@chromium.org>
Commit-Queue: Chirag Arora <heychirag@google.com>
Reviewed-by: Rainhard Findling <rainhard@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1623012}
The upstream change moved the top container layout calculation into an
Impl method in BrowserViewTabbedLayoutImpl and internally now calls the
Impl method instead of BrowserViewTabbedLayout which is virtual and the
one we were overriding. Made the Impl method virtual and now we are
overring it instead.
Chromium change:
https://chromium.googlesource.com/chromium/src.git/+/450301153d05f
commit 450301153d05ffd001bafa2622ba031cd6e62fc6
Author: Dana Fried <dfried@chromium.org>
Date: Wed Apr 29 07:39:52 2026 -0700
[Chrome Next] Ensure separator is hidden in infobar+thsp+vts
This fixes a corner case where a separator would be drawn in the top
container when vertical tabs + toolbar-height side panel + an infobar
are present in the browser.
This makes the suppression of the separator consistent regardless of
whether the separator is drawn in the top container or multi-contents
view area.
Fixed: 507565700
The upstream CL rewrote the `DownloadDisplayController` unit test as a browser
test, rewriting the fixture to use `InProcessBrowserTest` with a real `Browser`.
Before the conversion, the unit-test fixture didn't wire
`DownloadBubbleUIController` / `DownloadBubbleUpdateService` into a real
`Browser`, so `OnNewItem` -> `UpdateButtonStateFromUpdateService` never reached
our `chromium_src` override. As a browser test it does, and the mock's
`GetDisplayInfo` populates `info.all_models_size` while `GetAllModelsToDisplay`
(un-mocked, hitting the real empty cache): returns nothing, hitting the invalid
`DCHECK`.
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/3472777e7f3fa
commit 3472777e7f3fa14c8f76715c482b3956e9702c9a
Author: Daniel Rubery <drubery@chromium.org>
Date: Mon Apr 27 13:36:09 2026 -0700
[bedrock] Convert download_display_controller_unittest to browser test
This CL removes the dependency on a mock browser by converting the test
to a browser test. This simplifies the Browser setup. In order to
effectively test the OneShotTimers in the DownloadDisplayController, we
add the ability to inject a task runner.
Bug: 506197563
Bypass-Check-License: Moved files
Link: https://chromium-review.googlesource.com/id/I52973dddafcf4cfd73a356343c4e80f96a6a6964
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7791256
Reviewed-by: Darryl James <dljames@chromium.org>
Auto-Submit: Daniel Rubery <drubery@chromium.org>
Commit-Queue: Darryl James <dljames@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1621286}
This is now just `extra_build_script_input_roots`.
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/3197ca477e1f00cc6252cf79bb31c5bc87dc1a6d
commit 3197ca477e1f00cc6252cf79bb31c5bc87dc1a6d
Author: Lukasz Anforowicz <lukasza@chromium.org>
Date: Mon May 4 11:37:30 2026 -0700
[gnrt] Use `..._input_roots` for everything and remove `..._src_roots`.
This change avoids the following problems:
* Having to say `extra_input_roots = ['../data']` **and also**
`extra_src_roots = ['../data']` in `gnrt_config.toml` entries for
multiple ICU crates. The repetition was introduced because
`..._input_roots` ignores `.rs` files. But in both cases the
discovered files are exposed as GN `inputs` (not `sources`).
This was reported a while ago by @manishearth in chat, but I forgot to
open a bug and follow-up... :-(
* General confusion about how things work, which was encountered when
tweaking import of `zerocopy` for fuzzing. This was reported recently
and captured in https://crbug.com/508339800.
Before this change `extra_input_roots` wouldn't cover `.rs` files, so
the removal of `extra_src_roots` means that `extra_input_roots` has to
also cover `.rs` files after this change. This in turn means that we
need to explicitly list files one-by-one in
`build/rust/std/gnrt_config.toml` to avoid adding unnecessary `.rs`
files to the generated `BUILD.gn`. This is a bit unfortunate -
hopefully this will be fixed by adopting `glob` or a similar globbing
crate in a follow-up CL.
Tested by manually running the following tools (and including the
results in this CL):
* `tools/crates/run_gnrt.py gen`
* `tools/rust/gnrt_stdlib.py`
* `cargo test` and `cargo clippy` in `tools/rust/gnrt`
Bug: 508339800
Change-Id: I4db48ca9f5f215a3b5daaa42e9fd4df9e2c122b0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7810294
Reviewed-by: Devon Loehr <dloehr@google.com>
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1624842}
These changes have been automatically picked up on by `gnrt gen`.
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/36a5776a2fefd795a20d7f95a5f0eb64dd9ff75b
commit 36a5776a2fefd795a20d7f95a5f0eb64dd9ff75b
Author: Lukasz Anforowicz <lukasza@chromium.org>
Date: Mon May 4 15:09:18 2026 -0700
[gnrt] Allow wildcards and any file extension in `extra_input_roots`.
Rather than allowlisting extensions one-by-one, let's add support for
wildcards and let `gnrt_config.toml` pick which extensions to cover.
Other changes in this CL:
* It turned out that before this CL `extra_input_roots` was ignored for
"binary" crates (and only taken into account for "library" crates)
* Stop automatically enumerating non-`.rs` files under `src/`. This
was somewhat okay when only allowlisted extensions were included, but
would result in lots of extra files after this CL. (And also, this
removes some unneeded `BUILD.gn` entries here and there.)
* Globbing means that we no longer need to manually match extensions
in `fn collect_crate_file` so this function has been inlined
and refactored away.
Tested by manually running the following tools (and including the
results in this CL):
* `tools/crates/run_gnrt.py gen`
* `tools/rust/gnrt_stdlib.py`
* `cargo test` and `cargo clippy` in `tools/rust/gnrt`
Bug: 508339800
Change-Id: Ieb6b0d7205b407f921272bf5ad7c7bc54f355f32
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7809525
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Reviewed-by: Devon Loehr <dloehr@google.com>
Cr-Commit-Position: refs/heads/main@{#1624964}
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/3498e7937705733e97710a4337693fa42c2002cb
commit 3498e7937705733e97710a4337693fa42c2002cb
Author: Patrick Noland <pnoland@google.com>
Date: Fri May 1 09:57:26 2026 -0700
Wrap tablet LocationBar in a holder layout
This allows us to allocate the width/height to this view, keeping
everying in the same position while reparented. It also simplifies the
alignment view issue; this holder can stay the alignment view in all
tablet scenarios.
NO_IFTTT=Uses the same consumer as the location bar
Bug: 507111601
Change-Id: Ia6a5a602bc94462100a0a815f82e119dd92eb853
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7801292
Reviewed-by: Sky Malice <skym@chromium.org>
Commit-Queue: Patrick Noland <pnoland@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1623882}
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/20e810aa6ee8a292cf548efac7a4c64dbe0b6821
commit 20e810aa6ee8a292cf548efac7a4c64dbe0b6821
Author: Alison Gale <agale@chromium.org>
Date: Thu Apr 30 09:15:18 2026 -0700
[Vertical Tabs] Fully enable vertical tabs on ToT
This applies to just Windows/Mac/Linux. ChromeOS is still launching so I
updated the field trial config to just leave those values.
Had to fix one unit test to handle the missing immersive controller
Bug: 493628274
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/9d9fbd3410b1f7fde453b6396fa5b16bd4db598d
commit 9d9fbd3410b1f7fde453b6396fa5b16bd4db598d
Author: Mike Wittman <wittman@chromium.org>
Date: Thu Apr 30 09:10:10 2026 -0700
[embeddings] Enforce embeddings normalization
Embeddings are guaranteed to be normalized in production. This
change documents that guarantee, removes the unnecessary Normalize()
and Magnitude() member functions, and updates Embeddings in tests to
be consistently normalized.
Bug: 499323089
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/beaae0fe841a3830d1f23fbe2579955d159a02cf
commit beaae0fe841a3830d1f23fbe2579955d159a02cf
Author: Thomas Lukaszewicz <tluk@chromium.org>
Date: Sun May 3 11:52:41 2026 -0700
[bedrock] Rehome UnloadHandler to BrowserWindowFeatures
There is no intended behavior change in this CL.
Future CLs will further refactor Browser methods to call the
UnloadHandler directly.
Bug: 502745808
Change-Id: I00d39b8c0a61ac3541465420bd9c6fb121a4fcbc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7805864
Commit-Queue: Thomas Lukaszewicz <tluk@chromium.org>
Reviewed-by: Allen Bauer <kylixrd@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1624444}
[cr149][WIP] Fixes not opening new tab on closing last tab.
We were relying on the order of notifications for TabStripEmpty to call
UnloadController before BraveBrowser and using the state of
UnloadController to make the decision on closing the window. With the
upstream change below the order is now reversed, but it's unclear to me
why we need to rely on UnloadController here since it's the same
notification.
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/beaae0fe841a3830d1f23fbe2579955d159a02cf
commit beaae0fe841a3830d1f23fbe2579955d159a02cf
Author: Thomas Lukaszewicz <tluk@chromium.org>
Date: Sun May 3 11:52:41 2026 -0700
[bedrock] Rehome UnloadHandler to BrowserWindowFeatures
There is no intended behavior change in this CL.
Future CLs will further refactor Browser methods to call the
UnloadHandler directly.
Bug: 502745808
Change-Id: I00d39b8c0a61ac3541465420bd9c6fb121a4fcbc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7805864
Commit-Queue: Thomas Lukaszewicz <tluk@chromium.org>
Reviewed-by: Allen Bauer <kylixrd@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1624444}
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/1ebf897333e83abfc1841f3c97ae114d935df850
commit 1ebf897333e83abfc1841f3c97ae114d935df850
Author: Ernesto Izquierdo Clua <eic@google.com>
Date: Wed Apr 22 05:13:21 2026 -0700
[ios] Implement Tab Grid screenshot protection policies
This CL implements the core business logic for Enterprise Screenshot
Protection in DataProtectionSceneAgent, specifically focusing on the Tab
Grid. Logic for protecting the window when displaying a single tab will
be added in a follow-up CL.
Key changes:
- DataProtectionSceneAgent observes ProfileState, TabGridState, and
IncognitoState to determine when protection should be active.
- Protection is updated when the scene is in the foreground, the
profile is fully loaded, and the UI is enabled.
- Implemented logic to track enterprise policies:
- EnterpriseRealTimeUrlCheckMode: Protects if real-time lookups are
enabled.
- DataControlsRules: Protects if a blocking SCREENSHOT rule exists.
- Added comprehensive unit tests in
data_protection_scene_agent_unittest.mm to verify state transitions
and policy enforcement.
Bug: 485585995
Change-Id: Iabdf96e33aa0adf08988f597b527b5f6ce0d7e22
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7767015
Commit-Queue: Ernesto Izquierdo Clua <eic@google.com>
Reviewed-by: Gauthier Ambard <gambard@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1618786}
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/5adc915936b90ddebf40821b4cfd1ff29d5ca307
commit 5adc915936b90ddebf40821b4cfd1ff29d5ca307
Author: Samuel Huang <huangs@chromium.org>
Date: Fri May 1 11:52:17 2026 -0700
[Lens Overlay] Add App Menu entry point and JNI scaffolding
This CL introduces the initial Android App Menu entry point for the Lens
Overlay feature on Android, alongside foundational Java-to-C++ JNI
scaffolding.
Implementation follows a staged approach:
1. Short-term (Current focus): Build an "Intent-based handoff" pipeline
that captures a screenshot, formats it for external consumption, and
delegates the search flow to the Google Lens app (AGSA) via Intent.
2. Long-term: Host a Chrome-native overlay that provides the feature's
WebUI directly within the browser, reusing existing Desktop code.
The JNI bridge established here provides the functional entry point for
the Stage 1 screenshot and handoff logic. In this initial CL, it is
utilized to invoke shared C++ metrics code to ensure immediate
feature-parity in tracking with the Desktop implementation.
Since our ultimate goal is to align with Desktop functionalities, we
reuse strings and shared code as much as is practical.
Note: The feature is temporarily disabled in Incognito mode. Because
the short-term implementation delegates to Google Lens (an external
app), disabling it in Incognito prevents sending user data across app
boundaries without explicit consent. We anticipate enabling Incognito
support in the long-term implementation (matching Desktop behavior).
Details:
* Add IDS_LENS_OVERLAY_APP_MENU = "Search with Google lens" (same as the
Desktop string) as an Android-specific asset. We duplicate for now to
avoid massive asset refactorization.
* Add the "Search with Google Lens" item to the App Menu
(`TabbedAppMenuPropertiesDelegate`), placed between "Find in page" and
"Translate...".
* Guard the new UI behind the `ChromeFeatureList.LENS_OVERLAY_ANDROID`
feature flag.
* Create `LensOverlayCoordinator` (Java) and
`LensOverlayControllerAndroid` (C++), bridging them via JNI to
establish the functional entry point for the feature.
* Hook the menu click into `RootUiCoordinator` to launch the
coordinator. This implements a dual-metrics strategy:
* Record Android core UI metrics via
`RecordUserAction("MobileMenuLensOverlay")`.
* Record Lens feature metrics (`lens::RecordInvocation()`) via the
C++ controller, which will handle slicing by document MIME type in a
future CL.
* Generate `LensOverlayInvocationSource` using `java_cpp_enum` to
mirror the C++ enum for accurate UMA histogram recording across the
JNI bridge, preventing future desyncs.
* Add unit tests to `TabbedAppMenuPropertiesDelegateUnitTest` to verify
the Lens Overlay menu item is correctly shown on standard web pages
and correctly hidden on the NTP, in Incognito mode, or when the
feature flag is disabled.
* Create `chrome/browser/ui/android/lens/OWNERS` to manage the new
feature directory.
Bug: 507533812, 493627069
Change-Id: I87eaaaee9b4e21f8071a3fd88666cb06ff4e2d3f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7800658
Reviewed-by: Calder Kitagawa <ckitagawa@chromium.org>
Commit-Queue: Samuel Huang <huangs@chromium.org>
Reviewed-by: Bryan Nguyen <nguyenbryan@google.com>
Cr-Commit-Position: refs/heads/main@{#1623965}
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/42937e4ba2e5d383daf6f0e057f5fe530ac1a451
commit 42937e4ba2e5d383daf6f0e057f5fe530ac1a451
Author: Andrew Grieve <agrieve@chromium.org>
Date: Fri May 1 06:38:05 2026 -0700
Initial prototype of WebUI NTP for Android
It only barely works, but sets the groundwork so that we can iterate
on the missing / broken functionality.
All changes are guarded behind GN arg: enable_webui_ntp, and also
behind a runtime flag: --use-webui-ntp.
This does not remove the native NTP, but instead navigates to:
chrome://new-tab-page/
instead of:
chrome-native://newtab/
Bug: b:502297163
Bypass-Check-License: Moved file
Change-Id: If5e535793fa20f67d8897aee2d6bf55e95af2fce
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7773408
Reviewed-by: Tibor Goldschwendt <tiborg@chromium.org>
Reviewed-by: Thomas Lukaszewicz <tluk@chromium.org>
Owners-Override: Andrew Grieve <agrieve@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Commit-Queue: Andrew Grieve <agrieve@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1623798}
This change is functionally the same, as it merely changes how the
underlying values are read from the new argument.
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/5ee42da3af8311556b84afb3dc2ff9bc0ca75b7b
commit 5ee42da3af8311556b84afb3dc2ff9bc0ca75b7b
Author: Chris Staite <christopher.staite@menlosecurity.com>
Date: Fri May 1 01:49:25 2026 -0700
Use GlobalRenderFrameHostId in speech recognition
Update `SpeechRecognitionSessionContext` and associated manager
delegates to use `content::GlobalRenderFrameHostId` instead of passing
`render_process_id` and `render_frame_id` as separate integer values.
This also applies to embedder frame IDs, which are now represented by
`embedder_global_id`.
This refactoring simplifies method signatures across the speech
recognition API, including `SpeechRecognitionManagerImpl` and
`OnDeviceSpeechRecognitionEngine`, reducing the risk of mismatched IDs
and improving overall code clarity when identifying render frames.
Bug: 379869738
Change-Id: I0bbf3f026b98428b706f2777ce327030e675720d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7805227
Reviewed-by: Devlin Cronin <rdevlin.cronin@chromium.org>
Commit-Queue: Christopher Staite <christopher.staite@menlosecurity.com>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Bo Liu <boliu@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1623755}
This change corrects the inclusion of this header everywhere, but it
also fixes one of the patches that were broken recently due to this
change.
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/42937e4ba2e5d383daf6f0e057f5fe530ac1a451
commit 42937e4ba2e5d383daf6f0e057f5fe530ac1a451
Author: Andrew Grieve <agrieve@chromium.org>
Date: Fri May 1 06:38:05 2026 -0700
Initial prototype of WebUI NTP for Android
It only barely works, but sets the groundwork so that we can iterate
on the missing / broken functionality.
All changes are guarded behind GN arg: enable_webui_ntp, and also
behind a runtime flag: --use-webui-ntp.
This does not remove the native NTP, but instead navigates to:
chrome://new-tab-page/
instead of:
chrome-native://newtab/
Bug: b:502297163
Bypass-Check-License: Moved file
Change-Id: If5e535793fa20f67d8897aee2d6bf55e95af2fce
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7773408
Reviewed-by: Tibor Goldschwendt <tiborg@chromium.org>
Reviewed-by: Thomas Lukaszewicz <tluk@chromium.org>
Owners-Override: Andrew Grieve <agrieve@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Commit-Queue: Andrew Grieve <agrieve@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1623798}
A few classes are being affected by these changes but they are mostly
incosequential overall.
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/e0f759f728337f7df2f808ebc2c1eefffab5c5e3
commit e0f759f728337f7df2f808ebc2c1eefffab5c5e3
Author: Athul Iddya <athul@iddya.com>
Date: Thu Apr 16 17:08:08 2026 -0700
Add a native frame view for non-browser widgets on Linux
Introduces NativeFrameViewLinux, a FrameViewLinux subclass that provides
native client-side decorations for non-browser widgets on Linux. This
class is preferred over FrameViewLinux for the GTK UI theme. Its
implementation mirrors BrowserFrameViewLinuxNative, using
WindowFrameProvider for frame decoration and NavButtonProvider for
window control buttons.
NativeFrameViewLayoutLinux similarly extends FrameViewLayoutLinux to
override frame and button layout decisions using WindowFrameProvider and
NavButtonProvider. Shared utilities between NativeFrameViewLinux and
BrowserFrameViewLinuxNative are extracted into frame_view_utils_linux.
WindowFrameProvider and NativeTheme gain options for non-browser frame
rendering: top area height, padding and border APIs, and bottom border
drawing in the top area, to match the appearance of native GTK dialogs.
Bug: 396190939
Cq-Include-Trybots: luci.chromium.try:linux-wayland-mutter-rel,linux-wayland-weston-rel
Change-Id: Iee94d493a1751176c38d793e7efcfe47271bc909
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7615475
Commit-Queue: Thomas Anderson <thomasanderson@chromium.org>
Reviewed-by: Thomas Anderson <thomasanderson@chromium.org>
Auto-Submit: Athul Iddya <athul@iddya.com>
Reviewed-by: David Yeung <dayeung@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1616203}
Artem Samoilenko