Chromium changes:
https://chromium.googlesource.com/chromium/src/+/8a572f986d8d90fe1befaa2792dabff71410b4db
commit 8a572f986d8d90fe1befaa2792dabff71410b4db
Author: Abdelrahman Eed <abdoeed@google.com>
Date: Tue Dec 16 11:20:41 2025 -0800
[Clank Navigation] Add support for user-modified (Shift-Click)
This CL adds support for the user modified navigation (Shift + Left
click) to launch a new browser window or an app if one is present
depending on the navigation source, for desktop devices.
Changes (only affecting desktop Android devices, or if we are on desktop
windowing):
- Launch a new chrome window if navigating from the chrome browser
- Launch an app to handle the navigation if navigating from a CCT
NO_IFTTT=the check is not working properly, I added the changes needed
Change-Id: I480eb5b648c7da281a83e592fec2b45d52a89631
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6662663
Commit-Queue: Abdelrahman Eed <abdoeed@google.com>
Reviewed-by: Michael Thiessen <mthiesse@chromium.org>
Auto-Submit: Abdelrahman Eed <abdoeed@google.com>
Commit-Queue: Michael Thiessen <mthiesse@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1559473}
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/9c2a3c87dbd2168e374e611422f9d815c67293ab
commit 9c2a3c87dbd2168e374e611422f9d815c67293ab
Author: Shuhei Takahashi <nya@chromium.org>
Date: Mon Dec 8 19:32:36 2025 -0800
extensions: Initialize extension UI post-native-init
This is a part of the patch series to use ExtensionActionViewModel on
Desktop Android.
We currently inflate the extension UI before native initialization,
following many other UI components. This is why we use OneshotSupplier
for ChromeAndroidTask because it is available only after native init.
As we update the extension UI to rely on browser-keyed shared view
models, such as ExtensionActionViewModel, they would introduce many
OneshotSupplier<T>, which is going to be cumbersome.
This patch avoids the problem by moving the extension UI initialization
to post-native-init. After all, we don't show the extension UI before
checking the profile eligibility, whereas profiles are available only
after native init.
Bug: 448199168
Change-Id: Ib0ea1bbb6f0adfc868ddfc1e7eb653f9eb189361
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7214707
Reviewed-by: Patrick Noland <pnoland@chromium.org>
Reviewed-by: Masa Fujita <massan@google.com>
Commit-Queue: Shuhei Takahashi <nya@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1555878}
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/814d968251668c4eba1b96d961633a91467c1e12
commit 814d968251668c4eba1b96d961633a91467c1e12
Author: Michael Wu <mklw@google.com>
Date: Mon Dec 8 14:17:00 2025 -0800
Unify #getInstanceInfo() APIs
We have two #getInstanceInfo() APIs currently:
- getInstanceInfo()
- getInstanceInfo(@PersistedInstanceType int persistedInstanceType)
We should remove 1 in favor of keeping only 2. Existing call-sites of 1
should be appropriately updated to pass PersistedInstanceType.ANY.
Bug: 467083292
Change-Id: I94decc397bebf483992eebf171d54e901a40c5ac
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7237457
Commit-Queue: Michael Wu <mklw@google.com>
Reviewed-by: Sirisha Kavuluru <skavuluru@google.com>
Cr-Commit-Position: refs/heads/main@{#1555733}
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/416a61c418c152a7a7ae568d89302e5ecb6e4a3d
commit 416a61c418c152a7a7ae568d89302e5ecb6e4a3d
Author: Andrew Grieve <agrieve@chromium.org>
Date: Tue Dec 2 14:13:59 2025 -0800
Android: Split ObservableSupplier into Nullable / Monotonic / NonNull variants
The goal is to use proper @Nullable annotations with
ObservableSuppliers.
To achieve this, we use interfaces that define nullness:
* (Settable)NullableObservableSupplier
* (Settable)ObservableSupplier <-- monotonic
* (Settable)NonNullObservableSupplier
And we have ObservableSupplierImpl implement all of them.
In order to make this migration manageable, I've marked the interfaces
as @NullUnmarked, and will fix annotations in batches until they
can be marked @NullMarked.
This CL includes a batch in order to test out the new interfaces (and
because many were necessary to make the change).
Monotonic suppliers are by far the most common afaict, so that's why
the non-prefixed ObservableSupplier is the monotonic one (that, and
because "Monotonic" is a mouthful).
One implication of this approach is that we'll never have:
ObservableSupplier<@Nullable Foo>
We'd have instead:
NullableObservableSupplier<Foo>
Having the nullness in the interface rather than in the generic
allows for defining toNonNull() only on monotonic suppliers, and
simplifies the implementation.
Bug: 455874046
Change-Id: Id48e235b9ff16a5b21a9c1199863150d17c22736
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7206746
Commit-Queue: Andrew Grieve <agrieve@chromium.org>
Reviewed-by: Calder Kitagawa <ckitagawa@chromium.org>
Owners-Override: Andrew Grieve <agrieve@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1553094}
Currently there is an async mojo call to check policies for Leo and
Rewards, that is an overhead and not needed, in fact it could be wrong
if the policies controlled by something else that is not Origin.
Resolves: https://github.com/brave/brave-browser/issues/52244
This moves files that are directly copied over chromium resources to a separate directory where they are checked to make sure that there is a corresponding upstream file. This is the first step in a series of changes to clean up branding.js https://github.com/brave/brave-browser/issues/51969
[Android] Hide Brave Rewards UI elements when disabled by policy
Implements policy-based visibility control for Brave Rewards across
Android UI. When BRAVE_REWARDS_DISABLED policy is active via Brave
Origin subscription settings, all rewards-related UI elements are
now properly hidden.
Resolves: https://github.com/brave/brave-browser/issues/51826
Implemented the animation to show while we shredding the site data,
at the end of animation added a fade out from the completely black
screen to the reveal.
Resolves: https://github.com/brave/brave-browser/issues/51535
---------
Signed-off-by: Vadym Struts <vstruts@brave.com>
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/63fb0f5689e4667f99afc9d2bf903515425aedf6
commit 63fb0f5689e4667f99afc9d2bf903515425aedf6
Author: Sirisha Kavuluru <skavuluru@google.com>
Date: Thu Dec 11 16:36:20 2025 -0800
[ToolbarRefactor] Trigger allocateAvailableToolbarWidth when zoom indicator is added to omnibox.
allocateAvailableToolbarWidth handles updating all toolbar views based on available layout width and is invoked during Toolbar#onMeasure(). However, location bar URL action container view updates (specifically toggling zoom indicator visibility) does not trigger onMeasure(). Invoking allocateAvailableToolbarWidth() manually for zoom indicator.
We might need to do the same for other buttons or pivot to a more scalable solution (eg: onGlobalLayoutChangeListener to listen to child view visibility changes) but landed this as a temporary fix to unblock zoom indicator + toolbar resize exp
Bug: 461853892
Change-Id: I22a8113f9a701b826528d7725c13cac78ccfec76
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7201190
Auto-Submit: Sirisha Kavuluru <skavuluru@google.com>
Reviewed-by: Hitarth Kothari <hitarthkothari@google.com>
Reviewed-by: Charles Hager <clhager@google.com>
Commit-Queue: Sirisha Kavuluru <skavuluru@google.com>
Cr-Commit-Position: refs/heads/main@{#1557771}
STR to verify there is no crash:
1. Pin one shortcut
2. Turn background images off
3. Restart
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/a11ac5d97f40076f5d1502084c6ef8972cff2a22
[MVT] Fix MVT container sizing and centering on Tablets.
By "blocks" we include MVT tiles and the "Add now" button.
On Tablets, blocks and its container have special behavior:
1. Depending on **initial** block count, these render in modes:
* Centered: With "few" blocks present: The container is WRAP_CONTENT,
and "edge margins" (outer margin of outer blocks) expanded so blocks
are centered and immobile.
* Overflowed: With "many" blocks present: The container is
MATCH_PARENT, and "edge margins" are assigned a fixed value. The
blocks become scrollable.
2. When changing from "many" blocks to "few" blocks, the Overflowed
state remains. In this case, blocks no longer scroll, and are start-
aligned instead of centered.
(2) was intentional, presumably to reduce tiles "jumping" on repeated
tile removal. NewTabPageLayout (for container) and TilesLinearLayout
(for "edge margins") implemented this by doing the following:
* Store initial tile count and block count.
* Use these counts and width constants to compute "content width".
* If "content width" <= "container" size then Centered (AKA "full
filled", "all filled"); else Overflowed.
Now, MVT on tablets has some longstanding oddities
O1. When Centered, the container might not reach full width.
O2. Container may shrink on repeated tile removal (and centered) --
this is a cross between Centered (re. WRAP_CONTENT) and Overflowed
(re. fixed "edge margin") modes.
O3. When changing from "few" blocks to "many" blocks (by adding Custom
Tiles), Overflow mode does kick in sometimes, leading to blocks
appearing off-screen but cannot be scrolled to.
This CL fixes the oddities and removes behavior (2); now Centered and
Overflowed behavior depends on **current** (instead of the initial)
block count -- this fixes (O3). High level changes:
* Stop storing initial tile and block counts.
* Centralize Centered / Overflowed decision, including "content width"
computation, to MostVisitedTilesLayout.
* Change MVT child addition semantics from {Tile, non-Tile} to
{Tile, Divider, UI View (for the "Add new" button)}.
Bugs that were found and fixed:
* The duplicated Centered / Overflowed decision logic were inconsistent;
the NewTabPageLayout version (for WRAP_CONTENT / MATCH_PARENT) didn't
account for Custom Tile changes, i.e., divider & "Add new" button.
This led to (O2), and is fixed when we dedup the logic.
* When "divider gap" was changed to same as "tile gap" in
crrev.com/c/6780677 , we didn't update "content width" calculation.
This also led to (O2), and is fixed by having dividers not contribute
to "content width".
* Resources.getDimension() returns (float) PX value, and NOT DP. The
misunderstanding led to explicit conversions that made the width of
the "Add new" too large (TileRenderer.renderTileSection()). This led
to (O1). Fixing this also simplified code.
Bug: 447086773, 388782412
Change-Id: Id1400e672f1f0be11b4cc218cd20521988c3455f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7004884
Forced the color of pin icon at most visited strip to white color.
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/4aa1ff3579960b0946ab8707528e9b3299a929bd
[MVT Customization][Launch] Enable MostVisitedTilesCustomization (ToT by default).
This CL enables MVT Customization by default on Android:
* kMostVisitedTilesCustomization: Disabled -> Enabled.
This corresponds to the flag #most-visited-tiles-customization, which
was added in crrev.com/c/6199259 .
We will apply Finch 100% everywhere after this CL lands.
Bug: 388782412
Change-Id: Ib04f110b0fa7e6366264cbb071815c69033d1fc7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7169644
Artem Samoilenko