Chromium changes:
https://chromium.googlesource.com/chromium/src/+/55e44d63ae9fcb516aa390039db404871e3f310f
commit 55e44d63ae9fcb516aa390039db404871e3f310f
Author: Adam Raine <asraine@chromium.org>
Date: Tue Aug 19 09:27:43 2025 -0700
[Clank Desktop] Add install button to omnibox
This CL reuses the installability checks from `AppBannerManager` instead
of `AddToHomescreenDataFetcher`. The insatiability criteria should be
the same for each:
- `WebappsUtils::AreWebManifestUrlsWebApkCompatible` is true
- `data.installable_check_passed` is true
- `data.errors` is empty
Future refactors in this area should consider:
- Using the delegate pattern instead of inheritance
crbug.com/322342499
- Replacing `AddToHomscreenDataFetcher` with a connection to
`AppBannerManager`, reducing the amount of duplicate logic.
Bug: 430109659
Change-Id: Ia4237505fb45aefa1ab8e3789eb8af22289c3700
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6735615
Commit-Queue: Adam Raine <asraine@chromium.org>
Reviewed-by: Glenn Hartmann <hartmanng@chromium.org>
Reviewed-by: Dibyajyoti Pal <dibyapal@chromium.org>
Reviewed-by: Patrick Noland <pnoland@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1503393}
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/09316976243447de4c0b3979b3c00c747792fa98
commit 09316976243447de4c0b3979b3c00c747792fa98
Author: Hitarth Kothari <hitarthkothari@google.com>
Date: Tue Aug 12 13:48:48 2025 -0700
Consolidate single-tab reparenting into multi-tab methods.
This change renames `ReparentingMultiTabTask` to `ReparentingTabsTask`
and updates its `begin` method to accept additional parameters. All
instances of moving a single tab are now handled by the
`moveTabsToWindow` and `moveTabsToNewWindow` methods by passing a
`Collections.singletonList` containing the single tab. This removes
redundant single-tab reparenting methods from `MultiInstanceManager` and
its implementations.
Bug: 432819744
Change-Id: I03394cbd3ae0f9afb49065d40a4271c2adcbc78e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6841517
Auto-Submit: Hitarth Kothari <hitarthkothari@google.com>
Commit-Queue: Calder Kitagawa <ckitagawa@chromium.org>
Reviewed-by: Calder Kitagawa <ckitagawa@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1500399}
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/80937223ea10c49f6c9359d5174a0c9c7283e03c
commit 80937223ea10c49f6c9359d5174a0c9c7283e03c
Author: Peilin Wang <peilinwang@google.com>
Date: Tue Aug 5 09:08:14 2025 -0700
[Bottom toolbar] Don't animate position changes if changed in settings
When the bottom toolbar's position change is animated, the renderer is
driving the animation by sending the new offsets to the browser on every
animation tick.
However, if the position change was done in chrome's settings, the
browser won't get these updates (I'm guessing because the settings UI is
covering up the toolbar?) which is why BrowserControlsManager explicitly
updates the browser's offset when the position changes. However, this
doesn't work with BCIV, because it causes the browser to submit a frame
with the new height before viz receives the animation offset from the
renderer, so the controls could appear to be in the wrong position for a
frame or two.
The position of the toolbar was controlled by a boolean
SharedPreference. This CL adds more state to this SharedPreference, to
include where the update came from. With this CL, if the update came
from the settings page, the position change will not be animated.
Bug: 433524798
Change-Id: Ic47106b1caec3d99752550edb54476f773553b2e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6811960
Reviewed-by: Patrick Noland <pnoland@chromium.org>
Commit-Queue: Peilin Wang <peilinwang@google.com>
Cr-Commit-Position: refs/heads/main@{#1496957}
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/cbdcbecdf3292b68c698532cbde53d41dc332cff
commit cbdcbecdf3292b68c698532cbde53d41dc332cff
Author: Joel Hockey <joelhockey@chromium.org>
Date: Fri Aug 8 13:06:38 2025 -0700
Disable drag-drop of files such as images replacing tab for CCT
Support for drag-drop of files was recently added to clank which had
the unintended side effect that dropping a file into a page in a
CCT / TWA which is not registered to handle the drop event will
replace the tab contents with the file (e.g. image).
This fixes clank to set the accept_load_drops param to false for CCT
to match the behavior of PWAs on other platforms.
Bug: 409632787
Change-Id: I4340b11eede64ab0c66ed790ca95db50e3bc70e1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6814772
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Joel Hockey <joelhockey@chromium.org>
Reviewed-by: Michael Thiessen <mthiesse@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1498987}
* [Android] Initial integration of Brave adaptive buttons
The Bookmarks button is the first in the list; the rest of the buttons will be added in separate PRs.
Important notes:
- override via `chromium_src` doesn't work for `patches/chrome-browser-ui-android-toolbar-adaptive_toolbar_enums.h.patch` since this file is parsed by `java_cpp_enum.py` to convert it to java enum
- patch to `java_cpp_enum.py` was added to be able to do 1 line patch, since upsteam parses each value as a separate line
- in `patches/chrome-browser-ui-android-toolbar-adaptive_toolbar_enums.h.patch` were added values for all planned Brave buttons to avoid additional patching for each consecutive PR
* Python patch optimisations
* Presubmit fixes
* Remove python patch in favour of multiline header patch
Unify the Android Rich NTT for reuse on iOS
The current PR is pre-requisite of Dynamic NTT on iOS as it allows
to reuse android `New Tab Takeover WebUI` on iOS. The PR removes
dependency of android `New Tab Takeover WebUI` from
`ViewCounterService` which is not available on iOS. It also removes
`current_wallpaper` base::Value cache in ViewCounterService which
allows to save memory and makes code cleaner.
Sometimes scanning QR codes searches for the URL within
search.brave.com rather than either loading the targeted URL or
displaying the URL within the omnibox so the user can load the
website that was scanned.
Resolves: https://github.com/brave/brave-browser/issues/48806
The custom menu item preference screen follows the Figma design and is composed by two sections, Main menu and Page actions.
The screen shows only those items that are supported by the device, items that will never appear won't be shown.
Each item's visibility will default to true and each preference is saved on shared preferences.
The only two items whose visibility cannot be modified are the Main Settings item and the Custom Menu item itself.
Let users to display only one tiles row in in quick action search
widget
There are cases on some devices where it is impossible to display
only one tiles row, it displays two right away.
Resolves: https://github.com/brave/brave-browser/issues/49110
The list was not updated nor maintained, and even had invalid entries.
On device which uses a local ML model was tied to this preference for some reason too, so that keeps the preference around and has a checkbox for just that now.
For Android, it doesn't support on device suggestions because the ML
models aren't available there, so no checkbox was added there.
* Move BraveYouTubeScriptInjectorNativeHelper to main app layer so it can reference BraveActivity
* Save boolean flag in activity bundle
* Add small delay to let the layout pass to complete
When a user tapped on the radio button in the VPN region (country)
selection screen, it did not have a click handler which resulted in the
user's interaction being dispatched to the parent container for that
row, causing them to be brought to the next screen where they choose a
city.
Now, the radio button handles clicks and will switch them to that
country. The optimal region is always chosen within the code. Users can
still tap on the row entry itself to access the city selection screen.
Closesbrave/brave-browser#48327
When we call into `BraveVpnPrefUtils.setPrefModel`, this function
invokes a method or two that `assert` they're being called on the UI
thread. As a result, previously, the VPN would fail to start in debug
builds as a result of the assertion and could possibly have been causing
breakage in Release builds.
Additionally, a couple of functions have had a null-check added which
causes them to return without doing anything. Prior to this commit, an
exception would be thrown immediately when passed to `setString` which
then resulted in the function not doing anything anyway - along with
negatively impacting any code further up the call chain that didn't
handle the exception.
There was also a problem with the VpnServerSelectionActivity wherein a
member of the class implemented AutoCloseable but was not being closed
in all cases which then resulted in a runtime exception because the
object detected it was freeing its resources by being finalized. A
missing close() has been added and we also handle onDestroy() to close
the object there too.
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/6853852a6e345346bb9b0578c83b5b7989e8b3ad
[Android][Signin] Move sign-in operation to bottom sheet mediator
The main goal of this CL is to move the sign-in related operations and
the use of SigninManager from the AccountPickerDelegate implementations
to AccountPickerBottomSheetMediator.
It also add a sign-out operation right before sign-in if there's an
existing account. This behavior was previously implemented only for the
web sign-in entry point, but it also makes sense for the other flows.
The SignoutReason enum description is updated accordingly to state it's
not only used by the web-signin anymore.
The tests are updated accordingly.
Bug: 431198423, 40646656
Change-Id: I9ac9f3410cba714d16a1dd02b46f1d69afcf0eb2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6759794
- new arg bringTabGroupToFrontCallback at LocationBarCoordinator.ctor;
- new arg bringTabGroupToFrontCallback at AutocompleteMediator.ctor
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/9bc7b331449ea2da29ce2d705d5b725f5688127f
[hub] Prototype adding an intent for opening tab groups from hub search
Add logic for opening up a BRING_TAB_GROUP_TO_FRONT intent with logic
for hub search. This flow follows an established pattern in the
BRING_TAB_TO_FRONT (switch to tab) path and needs to work from all
contexts such as SearchActivity.
Validate-Test-Flakiness: skip
Bug: 431020549, 435216330
Change-Id: I273c802cd28ff1f36d5e1aef6e4085772cf74699
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6795745
- new ephemeralTabCoordinatorSupplier arg at BaseCustomTabRootUiCoordinator.ctor
- changed type from OneshotSupplierImpl to ObservableSupplierImpl at TabbedRootUiCoordinator.ctor
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/8d210f0ad7b7edb9414d856391403b3773128dc1
[BNPL][Ephemeral] Add EphemeralTabCoordinatorSupplier in ChromeActivity
For BNPL (Buy Now, Pay Later) on Clank, when a user selects a BNPL
issuer, we redirect them to that issuer's site using ephemeral tabs.
To facilitate this, we need to access EphemeralTabCoordinator
from PaymentsWindowCoordinator, for which we are creating a
supplier.
Design:go/clank-bnpl-ephemeral-tabs-engineering-design
Bug: 430575808
Change-Id: Iaccfbcc59a50bcce22f8f623801dbf066bfe6483
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6776167
Fix for EphemeralTabCoordinator
Artem Samoilenko
