* [AI Chat] Don't show Task UI when executing tools in a non-agent conversation
It's a pretty cumbersome UI that is more suitable when the conversation is performing potentially disruptive actions, like using the browser.
- Send the current conversation capabilities to the UI (currently a static list, so does not need events to update)
- Test the UI is not shown for chat conversation (we already test that it does show for agent conversations)
- Don't set the ToolUseTaskState to RUNNING when we're waiting on user input (in the future we'll probably add a WAITING state)
* Resets visibility and clip path when horizontal scrolling is disabled.
When horizontal scrolling is disabled, we should reset the visibility
and clip path of all tabs to make them visible and have no clip path.
* Update comment
* Scoped trace from helper function
Resolves: f/u PR to #36273
Manual test:
Add any payments info to Chrome and close
Go to brave://settings/importData and check no Payment methods checkbox
* [VPN 2.0] BoringTun 3p dependency: build script and GN buildflag
This is a multi-part change to add BoringTun dependency to the brave-core, to be used later in the VPN 2.0 architecture by a privileged helper on desktop OSes. The dependency is added to the existing VPN to ensure it actually gets built with the browser, but not yet distributed.
Part 5: build script that actually builds BoringTun dependency in an isolated bundled Rust/C++ environment; BUILD.gn that passes the necessary arguments to the script; GN buildflag 'enable_brave_vpn2_deps' that controls whether VPN 2.0 dependencies are getting built; off by default until we actually start using the dependency.
* [VPN 2.0] BoringTun 3p dependency: fix build script and turn off CI
The following changes have been made:
- Switched to the standard logging module, but still keeping the "quiet" logic.
- Moved platform-specific executable names to contants, removing the _exe_name function.
- Turn off building in CI temporarily.
Fix SERP metrics tests flakiness
The PR advances time in SerpMetrics tests to a fixed date so they have a predictable
starting point regardless of what time MOCK_TIME sets on any given machine. When
MOCK_TIME starts near Unix epoch on January 1, 1970, calling UTCMidnight causes
InSecondsFSinceUnixEpoch to serialize the result to 0.0. Deserializing that value via
FromSecondsSinceUnixEpoch produces a null Time rather than UnixEpoch, and calling
UTCMidnight on null hits a DCHECK.
The previous AND check skipped scaling for images that exceeded only one
of the target dimensions (e.g. 8000x760), letting them be PNG-encoded at
full resolution and bypassing the intended ~5MB upload cap.
This change does further restruturing to `tools/cr`, as now we are fully
reliant on paths being completely relative, and derived primarily from
`Repository.brave.root` as an anchor for all other relative paths.
With relative paths already landed, we can now further break down
`alias`, and make tests more reliable, by using `FakeChromiumSrc`
sandboxing for all tests. In particular, `tools/cr/commit.py` has also
been introduced, and now the hook destination path is fully relative to
`brave-core` root. This potentially fixes a recurring issue that in some
cases running tests for `install-hook` was uninstalling hooks in the
current `brave-core` checkout.
As an additional, `git cr` calls were not propagating the `cwd`
correctly, and this can now be corrected too.
This change also adds a README.md, to provide some overview of this
path, and some instructions that may be useful to be picked by AI agents
when writing tests.
For better guarantees, `vpython3_utils.py` now handles the file path
resolution to the vpython3 runtime across all applications in this path.
Finally, logging policy is now established with a default logger for
anything using `terminal.py`. This logger can be replaced by individual
applications, but it is of great benefit to be able to call anything
using `terminal.py` with `--verbose` at any moment.
This changes adds a new test helper to allow populating the query filter rules when the query filter component is enabled. This helps outside test clients that relied on hardcoded rules previously to test query stripping functionality. The hardcoded rules are going away once the `QueryFilterComponent` flag is enabled.
This change updates the two existing test suites to support the change when we migrate to the new query filter component. Please see the larger [change](https://github.com/brave/brave-core/pull/36222) to see the full integration.
Note that for now the test suites would *continue* to test the hardcoded rules despite this change as the actual query filtering is not yet supported. However, the plan is that once we do, these test suites would not need to be modified and they will automatically tests the new behaviour.
Resolves https://github.com/brave/brave-browser/issues/55418
* Respect vertical tabs on right for toggle placement
Add logic to position the vertical-tab-toggle button according to the brave_tabs::kVerticalTabsOnRight preference. Introduces BraveToolbarView::UpdateVerticalTabTogglePlacement(), wires up a pref listener (vertical_tabs_on_right_) and calls the updater during Init and when the pref changes. The method reorders the toggle within the location bar container to sit just left of the app menu when tabs are on the right, or just left of the back button when tabs are on the left, with guards for display mode and missing children. Adds a browser test to verify the toggle moves when the pref is flipped.
* Update brave_toolbar_view_browsertest.cc
* Address review feedback: CS-021, CS-025, TI-014
* Update brave_toolbar_view.cc
* Pin vertical-tab toggle to index 0 when tabs on the left
SimonHong feedback on PR #36301: avoid deriving placement from back
button index so future pinning/upstream ordering cannot invalidate
CHECK(GetIndexOf(back_)) or move the toggle unexpectedly.
Browser test asserts kVerticalTabsOnRight=false keeps toggle at child 0.
Co-authored-by: Cursor <cursoragent@cursor.com>
* Mirror vertical-tab toggle placement in RTL
The vertical tab strip is positioned by physical coordinates and ignores
UI direction, but the toolbar container uses a horizontal FlexLayout that
mirrors child indices in RTL. With `--force-ui-direction=rtl`, the toggle
ended up on the opposite physical side from the strip.
Invert the placement choice when `base::i18n::IsRTL()`:
on_right XOR RTL == true -> trailing slot (just before app menu)
on_right XOR RTL == false -> leading slot (child index 0)
Adds a `BraveToolbarViewRTLTest` fixture that appends
`--force-ui-direction=rtl` and asserts the inverted indices for both pref
states.
Co-authored-by: Cursor <cursoragent@cursor.com>
---------
Co-authored-by: Cursor <cursoragent@cursor.com>
Adds a new helper class to facilitate extractions of all blocked listed params from a given rule set for a spec. This change is a smaller change of https://github.com/brave/brave-core/pull/36222 where it specifies more details on how the helper method would be used one the client side.
This change also adds units tests for the same.
Resolves https://github.com/brave/brave-browser/issues/55412
This change makes the code for `git-cr` tools more modular. This will
help with test correctness ultimately, as now we are depending fully on
`Repository` for paths, specially install paths, which eliminates a
recurring issue where tests do seem to interfere with the current
install path `brave-core`.
This PR changes how we structure path resolution around all the
utilities under `tools/cr` to be truly relative, with all paths
ultimately being derived from the path for the brave repository. This
should make testing in sandboxing more reliable, as we can just rely on
the CWD to override behaviour in a consistent way across multiple tools,
even if they are being launched as a subprocess, which is not possible
when using mock patching for global constants.
This change eleminates the need for `FakeChromiumSrc` as its main use
was to patch `Repository` to use the path of the `tempdir` provided by
`FakeChromiumRepo`.
After this change, all should stay the same, however this change also
does away with `BRAVE_CORE_PATH`, and replaces it with
`repository.brave.root` as a more idiomatic way to indicate a
`brave-core`'s root path.
The main side effect of this change is that now both `brockt`, and
`plaster` should just work by being called anywhere under `brave/`.
Resolves https://github.com/brave/brave-browser/issues/55404
Minimize plaster related to PageActionController/Model
In order to make patching strategy more robust agains upstream chagnes,
we should prefer `chromium_src override without #define macro' to
'complex plaster'.
Co-authored-by: Claudio DeSouza <cdesouza@brave.com>
Importing payment info requries use of os crypt, which in cr149 will
be async only and that is much more involved when used in an utility
process and requires a different key. We already removed importing
Chrome passwords in the past so this is just a continuation of that
decision.
Chromium change:
https://chromium.googlesource.com/chromium/src.git/+/a4cab4afb48c24f4557ec6dc7cbd1bd192fb65b4
commit a4cab4afb48c24f4557ec6dc7cbd1bd192fb65b4
Author: Tom Anderson <thomasanderson@chromium.org>
Date: Fri Apr 17 15:10:45 2026 -0700
[OSCrypt] Remove sync backend
R=thestig
Fixed: 447372315
* [Ads][Origin] Defer ads service start until policy service is initialized
The ads gate reads `kDisabledByPolicy` via `IsManagedPreference`, so if
`AdsServiceImpl` is constructed before the BraveOrigin policy bundle has
been merged into the managed pref store, the gate evaluates as unmanaged
and the service starts. NTT ads can then serve despite
`BraveRewardsDisabled` being active.
Defer the initial `MaybeStartBatAdsService()` call until
`PolicyService::IsInitializationComplete(POLICY_DOMAIN_CHROME)` is true.
Adds `[AdsGate]` diagnostics behind the existing "Verbose Logs for
Ad-Rewards" QA toggle.
Resolves: https://github.com/brave/brave-browser/issues/55228
Anton Paymyshev