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
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/9afc53ae9f2e324d23f4417840980f48a66c7a21
Animate compact mode expand/contract
This is accomplished with the transition framework. LBC is notified
right before layout changes corresponding to compact mode state changes
are made, allowing it to capture values at the right time. The location
bar itself and the "+" button are animated.
In order to animate contraction correctly, the Toolbar needs to remain
larger until the animation ends to avoid clipping the LocationBar.
LocationBarEmbedder allows for the toolbar's height to temporarily fixed
without exposing the view directly.
In order to provide consistent notifications re: compact mode state, we
need to create a single source of truth for compactness, extracting the
view binder's control of this property out to the mediator.
Bug: TBD
Change-Id: I40943b27b0e295c6bc83fb9b541d6d2f57396a69
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7171390
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/42c529f984e74c8bba3b8ced4b9e1d531252ff08
Ensure AIM/NB suggestions are fulfilled with appropriate tools.
Up till now only user-typed text was triggering appropriate
fulfillment. This change ensures that suggest picks do the same:
when the user is in AIM or Image creation mode and interacts with any
of the suggested items, they will be redirected to appropriate tool.
For the lack of a better alternative and insufficient time this change
follows the Desktop implementation: construct the AIM URL from its
Search URL analog.
Screen: http://screen/4azQvKA3MTThdrL.png
Change-Id: I04a85ad65de0aae5edf4979c591748771974b0ce
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7164817
To adjust Brave's controls these were done:
1) changed position of `qr_button`;
2) vertical alignment of buttons at location bar was tied to parent.
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/7b8b84c0af533e0e14d40219e01b403be2898b65
Drop url action bar container
The change aims at keeping as much fidelity to the original nested
linear layout as possible, while permitting the mic and lens buttons
to be anchored below the Omnibox/not impacting the Omnibox layout.
The change applies translationX to specific icons presented on the
NTP only, and replaces the mUrlActionContainer.setVisibility() with
a dedicated (boolean) member controlling visibility of all views
independently.
The change is needed to match our layout with the intended multimodal
layout, and will permit us to add a dedicated `Send` button to the
Omnibox
Bug: 452128478
Change-Id: I023ea2802f0493cf58607b06e7143e768ff43e12
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7088532
android.support.annotation.NonNull is not used at code anymore.
The only exception is SafetyNetClient, so moved lib here from upstream cr142:
src/third_party/android_deps/cipd/libs/com_android_support_support_annotations/support-annotations.jar
src/third_party/android_deps/libs/com_android_support_support_annotations/README.chromium
src/third_party/android_deps/libs/com_android_support_support_annotations/LICENSE
Otherwise there are build errors
```
Missing class android.support.annotation.NonNull
(referenced from: com.google.android.gms.safetynet.SafetyNetClient
com.google.android.gms.safetynet.SafetyNet.getClient(android.content.Context)
and 2 other contexts)
```
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/b3748a2d55040afbbccd651513dedbac2d12799b
Remove legacy android.support.annotations 3p library
Bug: 455582944
Change-Id: I9ce7495883574e7f0bdc09dcc2960abce71a54a6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7081697
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/ec21aa685072efe21773e95ebef277e5bfa39214
extensions: Use BrowserWindowInterface in ExtensionViewHost
When we didn't have BrowserWindowInterface, we introduced an
Android-only signature of ExtensionViewHost::CreatePopupHost() that
takes Profile* instead of Browser*. As we move to use the common action
logic in ExtensionActionViewController, we should use BWI instead.
This patch updates the UI classes to pass around ChromeAndroidTask that
corresponds to BrowserWindowInterface. Then ExtensionActionPopupContents
can now pass it to the C++ layer via JNI.
Bug: 448199168
Change-Id: I003df88ee4e4f6f70d27753367b539a2bd571a9f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7089957
Added an ability to start shred manually from two places:
- tab's context menu (includes support of the menu customization)
- tab switch mode
Added confirmation dialog before the site data shred operation
Resolves: https://github.com/brave/brave-browser/issues/51326
---------
Signed-off-by: Vadym Struts <vstruts@brave.com>
* Remove `BraveFirstRunFlowSequencer` class
The sequencer only delays `initializeViews()` (the method called when
the callback is fired) until the account/child-status checks finish.
It does not influence which onboarding steps run or any prefs.
Given the current code, we can remove `BraveFirstRunFlowSequencer`
completely and simply call `initializeViews()` directly in both
`WelcomeOnboardingActivity` and `BraveVpnSupportActivity`.
The behavior will remain be the same, just without that async wait.
* Apply code formatting
Serg
