This command is a sibling to `reassign!`, in the sense that it also
creates a commit with a subcommand tag to guide a rebase event. In this
case though, the `drop!` indicates that a target commit is supposed to
be dropped during rebase.
Similar to `ressign!` handling, this type of pin can only be processed
with `--squash-minor-bumps`, and the target commit cannot be another
pinned commit.
This change is being implemented for rebase v2 only.
Bug: https://github.com/brave/brave-browser/issues/56150
This change updates the `update-xcode-toolchain` in brockit to work with
the index query we have now. This command will now maintain the several
task checks we have to do when bumping the toolchain.
Bug: https://github.com/brave/brave-browser/issues/55812
The singleton `ApplicationStateMonitor` caused a dangling pointer on
Linux because `BrowserCollection` could be destroyed before the
`ApplicationStateMonitor` singleton instance. To fix that the temporary
`Reset()` workaround was introduced in cr149 bump PR.
The PR changes `ApplicationStateMonitor` to be owned by
`AdsServiceImpl` eliminating browser shutdown issues cause by singletons.
Changing a setting and immediately restarting (e.g. "Restart now" on the
Brave Origin screen) could discard the change; waiting a few seconds avoided
it.
Pref writes are batched behind a timer and flushed to disk later. The Android
restart path SIGKILLs the browser process from a sibling process
(BrowserRestartActivity) with no graceful shutdown, so pending prefs are never
flushed. Whether a change survived depended on an unrelated write happening to
flush the store first, hence the intermittent, single-device reports.
Flush local_state and each loaded profile's prefs via CommitPendingWrite()
before AttemptRestart(). It is async-to-disk, a no-op when nothing is pending,
and the write is atomic.
Resolves: https://github.com/brave/brave-browser/issues/56075
Update the Polkadot Westend coins to display the associated Polkadot logo
instead of a default icon.
We need to manually add Westend Asset Hub as a supported testnet to get it
properly display as a testnet network.
Update the displayed wallet strings to show "Polkadot Testnet" for testnet
accounts.
This is useful because we're now supporting parachains, each of which can have
their own unique names which makes the usage of "Polkadot Westend" confusing for
users.
Captures the opengrep/reviewdog lint rule that flags new sources entries
in the source_set("ui") target due to //chrome/browser/ui circular
dependency risk. Adds BS-057 to build-system.md.
Co-authored-by: Bribot <bribot@agent.shared>
On a fresh profile with a prior Play Store Origin purchase, BraveActivity
auto-restores it at startup via verifyPurchase(). This enforces the Origin
policies (e.g. disabling Brave Wallet) live in the running session, but
unlike the in-settings purchase and the native web-purchase flows it never
prompted a restart. The browser then honours the freshly enforced policy
per navigation while already-configured renderers do not, which can leave
the two out of sync (e.g. the renderer keeps injecting window.ethereum and
requests a binder the browser no longer registers).
Open the Origin settings screen when a Play Store purchase is auto-restored,
reusing the existing fetching-spinner/restart snackbar, so the user restarts
and the policies take effect cleanly at boot. The prompt fires only on the
auto-restore transition (the subscription pref is inactive when verifyPurchase
runs); the in-settings first purchase keeps its own snackbar.
Resolves: https://github.com/brave/brave-browser/issues/56078
[AI Chat] Fix flaky AIChatConversationTaskBrowserTest GenerateAssistantResponse over-saturation
Problem:
- TaskStopAction and NoUpstreamGlicAndActorButtonsContainer intermittently
failed with "Mock function called more times than expected" on the
GenerateAssistantResponse WillOnce expectation.
Root cause:
- Both tests drive the real web_page_navigator tool, which completes
asynchronously and fires a follow-up GenerateAssistantResponse for the
tool-result round. That call could land on an already-consumed WillOnce
expectation when it fired during a RunUntil() pump before the next
expectation was installed.
Fix:
- TaskStopAction: install the next expectation before the RunUntil(kRunning)
pump instead of after it.
- NoUpstreamGlicAndActorButtonsContainer: add a Times(AnyNumber()) expectation
to absorb the follow-up response the test does not drive.
Make sure that creating a new account through a parachain still works.
For example, open a blank wallet and then attempt to deposit to an address
through the selected parachain. The UI will prompt the user to make a new
account for the given chain id and will subsequently fail because the keyringId
cannot be found.
Previously, round-robin filtering ran once across all ads before priority
bucketing, so a campaign that had exhausted its rotation could suppress
higher-priority campaigns from being served. This change moves the
round-robin filter inside the per-bucket loop so each priority bucket
rotates independently, preserving intended campaign priority ordering.
Pacing is also applied per bucket, after round-robin. If all ads in a
bucket are suppressed by pacing, the pipeline falls through to the next
priority bucket so lower-priority campaigns continue to backfill paced
out slots.
This PR adds a hash constant to the Xcode toolchain script, similar to
how upstream `MAC_BINARIES_TAG` on their counterpart of this source.
With this change we check the hash sum when downloading the file to make
sure it matches the expected hash.
Prior to this change, the decision to download/extract a new SDK was
entirely based on the version of the SDK found in the destination path.
This has served us well, however is a weaker scheme for reproducibility
checks. With this change, it is being introduced a scheme, similar to
how this type of check is done in other places, where a sidecar file is
created based on the name of the toolchain to be downloaded, and that
sidecar file has a hashsum in it.
With this new verification scheme we can now detect accidental
overwrites of the toolchain, but we can also leave the door open to use
issue a new toolchain under a subversion in case of some emergency fix
for a toolchain file
Finally, this change also corrects a few things across this source that
are outdated, and do not conform to the python style guide currently
enforced in Chromium, in particular the naming convention that was being
used.
Bug: https://github.com/brave/brave-browser/issues/55812
This PR adds a command to `brockit` to be used to update the Rust/WASM
toolchain. This command will take care of determining which version we
should be using, and going ahead and fetching whatever is available in
the bucket, based on the available indexes.
Bug: https://github.com/brave/brave-browser/issues/55812
Currently, SkusInternalsUI uses a call to the VPN connection manager
to get a last VPN error. This is relevant only to Architecture 1.0,
since in Architecture 2.0 there is no connection manager in the
browser. Hence we need to implement an implementation-agnotic API
in the BraveVpnService, to access the last VPN connection error in
SkusInternalsUI. This change introduces this new API.
Resolves https://github.com/brave/brave-browser/issues/55762
* Fix intermittent timeout in GlobalPrivacyControlBrowserTest.IncludesSecGPCHeader
The test was timing out on Windows x86 nightly (issue #55215). The timeout
occurred during the browser test startup flush, where all pending browser
startup tasks are drained via RunUntilIdle. On resource-constrained x86
machines, certificate verification overhead during HTTPS connections
contributed to the timeout.
Add ContentMockCertVerifier to bypass real SSL certificate verification
in the test. This eliminates certificate verification overhead during
both browser startup (for any HTTPS requests made by startup tasks) and
the test's HTTPS navigation. The test verifies Sec-GPC header presence,
not certificate handling, so mocking cert verification is appropriate.
Also fix GlobalPrivacyControlPolicyTest::SetUpInProcessBrowserTestFixture
to call the correct parent class method, ensuring the mock cert verifier
is properly initialized for policy tests.
Resolvesbrave/brave-browser#55215
* Enable HEVC/H.265 software video decoding on Linux
Adds FFmpeg-based HEVC/H.265 software decoding support for Linux,
providing a fallback when hardware decode is unavailable (e.g., NVIDIA
GPUs where VA-API is not functional in Chromium).
- chromium_src override for supported_types.cc (HEVC as built-in codec)
- brave/third_party/ffmpeg/sources.gni with HEVC source lists,
imported via ffmpeg_generated.gni patch
- Minimal patches for ffmpeg_common.cc and ffmpeg_video_decoder.cc
(anonymous namespace / file-local functions, not overridable)
- All HEVC code paths gated on BUILDFLAG(ENABLE_PLATFORM_HEVC) to
allow disabling via build args
- FFmpeg config patches for Linux x64 (config.h, config_components.h,
codec_list.c, parser_list.c, autorename wrappers)
- Enable enable_platform_hevc and enable_hevc_parser_and_hw_decoder
- Add ffmpeg to patch apply/update infrastructure with s.path guard
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* Address review: advertise HEVC support to web content on Linux
On Linux, upstream's IsDecoderHevcProfileSupported takes the
PLATFORM_HAS_OPTIONAL_HEVC_DECODE_SUPPORT path and consults the
supplemental profile cache, which is populated only by hardware
decoders registering via the GPU mojo interface. Since we ship a
bundled FFmpeg software decoder that never touches that cache,
MediaSource.isTypeSupported('video/mp4;codecs="hev1.1.6.L93.B0"')
returned false even though the decoder could handle the stream.
Override IsDefaultDecoderSupportedVideoType so that when upstream
rejects HEVC for that reason alone (cache empty), we fall back to
returning true. HDR, color space, and proprietary-codec gating from
upstream are preserved.
* Address review: round-trip new-file patches through apply/update_patches
Two related issues with how brave's patch tooling handles patches that
create new files (new file mode diffs):
apply_patches would fail on a fresh checkout with "Target file does
not exist" because isPatchStale treats a missing target as SRC_REMOVED
and bails out before apply. Teach it to recognize "new file mode"
patches and re-route through SRC_CHANGED so apply proceeds. Also
unlink any leftover target before apply so re-runs on an existing
checkout don't hit "already exists in working directory".
update_patches would silently delete new-file patches because
getModifiedPaths only inspected tracked/modified files. git apply
creates new files without staging them, so they show up as untracked
(??) and never reach the diff. Extend it to pick up untracked paths
that correspond to an existing patch, and generate their diff via
git diff --no-index /dev/null <path> to match the new-file-mode
format produced by git apply.
The four autorename_*.c.patch files in third_party/ffmpeg now round-
trip cleanly across apply/update cycles, which addresses the
"update_patches currently removes some patches you added here" review
comment.
* Address review: rebase HEVC patches onto Chromium 147 ffmpeg
Refresh patch index hashes to the current third_party/ffmpeg tree,
tighten the ffmpeg_generated.gni patch to avoid an empty line at the
hunk boundary (presubmit warning), and pick up libavcodec/x86/hevc/
dequant.asm, which upstream added since the original patch set and
whose absence caused an ff_hevc_dequant_8_ssse3 link error.
All four autorename_*.c patches, the config/config_components toggles,
the generated-list import, and the BUILD.gn include_dirs tweak now
apply cleanly on Chromium 147 and the resulting build links and plays
HEVC streams end-to-end.
* Address review: host autorename stubs in brave/third_party/ffmpeg
Moves the four HEVC autorename .c stubs from patches/third_party/ffmpeg/
into brave/third_party/ffmpeg/libavcodec/ (and libavcodec/hevc/) so
they're regular brave-owned sources rather than new-file patches against
upstream ffmpeg. This is what goodov suggested in review.
The stubs use fully-qualified includes like "libavcodec/hevc/cabac.c",
which resolve through the existing -I "." on ffmpeg_internal — so the
upstream source is what actually gets compiled, just under a different
object name to keep the linker happy. sources.gni references the new
files with absolute //brave/... paths.
One thing I missed on the first build: libavcodec/cabac.c and
libavcodec/hevc/cabac.c are two different files, and the hevc stub
needs to point at the latter or the linker complains about duplicate
ff_init_cabac_decoder. Fixed before pushing.
Since no new-file patches are left in the PR, the apply/update_patches
tooling changes from c1b2b937cf9 don't have a reason to be here anymore.
Reverted them — gitPatcher.js and updatePatches.js are back to where
they were before this PR.
Tested locally on Linux x64 component build: apply_patches and
update_patches round-trip cleanly, gn_check passes, ffmpeg and media
targets both build, and HEVC playback still works end to end.
* Address review: centralize HEVC enabled check via FFmpegSupportsHEVC helper
Introduces FFmpegSupportsHEVC() and HEVCAsH264IfFFmpegSupportsHEVC() in
chromium_src/media/base/supported_types.{h,cc}. The helpers wrap the
BUILDFLAG(IS_LINUX) && BUILDFLAG(ENABLE_PLATFORM_HEVC) check in one
place so callers don't have to repeat it.
Most of this is shrinking the existing patches:
- patches/media-filters-ffmpeg_video_decoder.cc.patch: drops the nested
#if BUILDFLAG blocks around the kHEVC switch case and IsCodecSupported.
The switch now reads `HEVCAsH264IfFFmpegSupportsHEVC(config.codec())`
so kHEVC reuses the kH264 threading branch, and IsCodecSupported maps
the incoming codec the same way before its kH264 comparison.
- patches/media-ffmpeg-ffmpeg_common.cc.patch: one-line
`if (FFmpegSupportsHEVC()) return "h264,hevc";` instead of a
C-preprocessor branch.
- chromium_src/media/base/supported_types.cc: IsDecoderBuiltInVideoCodec,
IsDefaultDecoderSupportedVideoType and IsDecoderSupportedVideoType all
go through FFmpegSupportsHEVC() now. The third one matters: blink
(webcodecs, media_capabilities) calls the public
IsDecoderSupportedVideoType, and the upstream definition calls
IsDefaultDecoderSupportedVideoType internally — which under our
#define rebrand routes to _ChromiumImpl and bypasses our override.
Overriding the public entry point too keeps the helper authoritative
whichever path the caller takes.
The override file now includes media/base/supported_types.h *before*
the rebrand #defines and forward-declares the *_ChromiumImpl variants.
That way the MEDIA_EXPORT declarations of the three Is* functions are
visible with their original names when our override definitions are
compiled, so the symbols get the right visibility without having to
repeat MEDIA_EXPORT on every override body. Verified by checking
`nm -D libmedia.so` — IsDecoderBuiltInVideoCodec,
IsDefaultDecoderSupportedVideoType and IsDecoderSupportedVideoType are
all exported, and media:media_unittests links cleanly.
sources.gni: collapses the two duplicated `is_linux && ffmpeg_branding`
conditions into a single `enable_ffmpeg_hevc_support` flag derived from
the upstream `enable_hevc_parser_and_hw_decoder` build arg. Drops
chromeos / fuchsia from the condition (not relevant for this PR).
Test adjustments for the new HEVC-supported reality on Linux:
- media_unittests: SupportedTypesTest.IsDecoderBuiltInVideoCodec and
IsDecoderSupportedVideoTypeBasics asserted HEVC=false unconditionally;
switched to `EXPECT_EQ(..., FFmpegSupportsHEVC())` so they pass on
Linux with the FFmpeg HEVC decoder built in and stay correct
everywhere else.
- browser_tests: EncryptedMediaSupportedTypesTest::CheckPlatformHevcSupport
asserted UNSUPPORTED for HEVC on Linux. With the software decoder
built in HEVC is supported via Clear Key too, so the assertion now
flips to EXPECT_ECK_PROPRIETARY when FFmpegSupportsHEVC() is true.
This fixes EncryptedMediaSupportedTypesClearKeyTest.Video_MP4 and the
two ExternalClearKey variants (Basic, Video_MP4).
Also renames the four autorename stubs to drop the "autorename_" prefix
and removes the "Auto-generated" wording from their comments — they
aren't produced by a script, they're hand-placed brave sources. The
sources.gni references are updated to match.
Verified on Linux x64 component build with chromium 149: gn_check,
format, presubmit, full brave build, SupportedTypesTest.* (32 tests)
and the four EME browser_tests above all green. HEVC playback + MSE
isTypeSupported confirmed end to end on a Main / Main10 / Level 5 test
clip.
* Address review: enable HEVC software decoder on linux-arm64
Mirrors the linux-x64 enablement on linux-arm64 so HEVC isn't a
brave-on-x64-only feature.
ffmpeg config patches: four new patches under chromium/config/Chrome/
linux/arm64/, symmetric to the existing x64 ones — flip CONFIG_BSWAPDSP,
CONFIG_HEVC_DECODER and CONFIG_HEVC_PARSER to 1, and add ff_hevc_decoder
/ ff_hevc_parser to codec_list.c / parser_list.c.
sources.gni: new `if (enable_ffmpeg_hevc_support && current_cpu ==
"arm64")` block pulling in the libavcodec/aarch64 HEVC NEON files that
upstream's Makefile lists for CONFIG_HEVC_DECODER (hevcdsp_init,
hevcdsp_{deblock,dequant,idct}_neon and h26x/{epel,qpel,sao}_neon).
Also introduce a `brave_third_party_ffmpeg_gas_sources` list — arm64
hand-written assembly goes through ffmpeg_gas_sources upstream rather
than ffmpeg_asm_sources (which is nasm-only). The ffmpeg_generated.gni
patch is extended to append it.
Verified: gn_check, format, presubmit all green. autoninja
third_party/ffmpeg:ffmpeg in a cross-compiled Component_arm64 build dir
links cleanly. Couldn't get a full media:media_unittests build past
unrelated clang segfaults on V8 torque-generated sources locally, but
that's host-side flake — the brave CI arm64 builders should hit a clean
environment.
Don't have arm64 hardware to runtime-verify; relying on CI for that.
---------
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This stores features that are unavailable in the group container similar to favourites to adjust how the shortcuts widget is displayed when features are unavailable due to Brave Origin or enterprise policies.
Applied rounded corners to panel's contents view.
Introduced brave::GetPanelContentsRoundedCorners(PrefService*, bool has_header)
which derives corners from the pref and current header presence.
Route GetRoundedCorners() through it via patch, reading header_view_ state
(set before AddChildView) instead of the stale coordinator entry ID.
Call UpdateContentWrapperChildCorners() from UpdateBorder() overrides so
corners are re-applied on panel open and pref change.
Resolves no issue - use umbrella issue (brave/brave-browser#51462)
TEST=SidePanelUtilsTest.*, SidebarBrowserTest.SidebarV2ContentCornersUpdateOnStateChange
`resource_component_` was held as a nullable `raw_ptr` but the
factory always provides a valid object. Changing it to `raw_ref`
removes the null guards throughout and adds a `CHECK_DEREF` in the
factory so a missing component crashes immediately.
To add a new BraveVpnService implementation based on Architecture 2.0,
which must co-exist with Architecture 1.0 for quite a while, we need
to split service's interface and implementation. All the external
components will keep accessing VPN service via the BraveVpnService
interface, but the implementation mostly goes into BraveVpnServiceImpl.
This change adds the second service implementation, BraveVpnServiceImpl,
for Architecture 2.0. It will live in a "components/brave_vpn/browser/v2"
subdirectory, but will eventually move into "components/brave_vpn/browser"
once V1 implementation has been removed.
Notable changes:
- fully testable BraveVpnServiceImpl v2 stub implementation, in a
dedicated "v2" namespace;
- BraveVpnServiceFactory can now create a proper implementation based
on the compile-time GN flags;
- v1/v2 include isolation using DEPS include rules (so that the
implementations can't depend on each other);
- stub unit test for BraveVpnServiceImpl v2.
Resolves https://github.com/brave/brave-browser/issues/54597
This reverts commit 31ac5c1ba8.
This change had been introduced under the impression we did not make use
of the hermetic toolchain to build the iOS code, but that's not
accurate. This is a partial revert of the change disabling the hermetic
SDK during the iOS checkout.
Bug: https://github.com/brave/brave-browser/issues/55812
* Produce metadata tests for parsing edge cases
These are some edge cases I found while doing some sec reviews with
an LLM. They seem like some good edge cases so the following commit
also addresses them to make sure the tests now pass.
cdesouza-chromium