Hides the "Show New Tab Page Ads" toggle and the
"Learn more about new tab page ads" link in
Settings -> New Tab Page when Brave Rewards is disabled by policy.
Both controls remain visible and functional otherwise.
Also switches BackgroundImagesPreferences to retrieve the profile via
the inherited getProfile() instead of the legacy
ProfileManager.getLastUsedRegularProfile().
Resolves: https://github.com/brave/brave-browser/issues/55312
[VPN 2.0] BoringTun 3p dependency: license information.
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 3: license information for Boringtun and its dependencies needed by Brave build system. Created a custom script to generate the necessary licensing information (README.chromium, and combined license files where appropriate) and put that information directly into the "brave/third-party/vendor" directory. The script should be re-run on updating the vendored crates.
Adds ARCH-072 to docs/best-practices/architecture.md. A KeyedServiceFactory
may only return nullptr based on session-stable attributes (profile type,
buildflags, base::Feature). Gating creation on user-toggleable prefs forces
restarts and was repeatedly flagged in PR reviews.
* Bridge web frames manager observer through Tab abstraction layer
- make brave_web_view conform CRWWebFramesManagerObserver
- add BraveWebFrame wrapper exposing web::WebFrame state to Swift
- notify BraveWebViewNavigationDelegate when a web frame becomes available
- propagate frameDidBecomeAvailable through TabObserver/TabState
* review(kyle): address feedback
* nit changes
1. rename brave_web_frame internal header file
2. add brave_web_frame_internal.h in gn file
3. other nit udpates
* fix typo
* [Origin] Wait for all policy managers before refreshing profile policies
`BraveProfilePolicyProvider` observes both `BraveOriginPolicyManager`
and `AdBlockOnlyModePolicyManager`. Each fires `OnBravePoliciesReady`
independently, so the first notification could call `RefreshPolicies`
before the other manager's `Init()` had run -- producing a bundle that
reflected only one source and flipping `IsFirstPolicyLoadComplete` true
on the empty load.
Introduce `BravePolicyManagerBase` with self-registration and a static
`AllInitialized()`. `OnBravePoliciesReady` early-returns until every
registered manager reports ready; `policies_ready_` is gated on the
same check so `SetProfileID` can't trigger a partial refresh either.
Future managers inheriting from the base are picked up automatically.
Resolves: https://github.com/brave/brave-browser/issues/55276
This PR introduces support for `cr mv` and `cr follow-renames` to
correct `gn` references across the projects when a `BUILD.gn` path
changes. This is a modest introduction to references path correction.
The rewrite does handle relative references though. In source references
are only corrected for the main target, i.e `:basename`, which gets
corrected to the new path base name.
This new approach also attempts to correct gn references to moved
sources, but only for `//` root reference paths. In the future we could
potentially introduce some mechanism handles file renames.
The baseline for this feature was to get the following to build with no
errors:
```
git cr mv components/api_request_helper/ components/api_foo
npm run build -- --target=brave:all
```
As a small detour, this PR adds `npm run format` to these commands, when
wrapping up. This PR also adds a README.md for the `alias` folder.
Resolves https://github.com/brave/brave-browser/issues/55297
This change uses a new label for plaster reapply commits, as the
previous name had `Regen` in it, which can cause confusion with the
similar command `brockit regen`.
When we using group APIs in tests, we need to ensure the tab group sync
service is initialized. Otherwise, the service could be initialized
later during shutting down and try to access Browser objects that are
already destroyed.
* Replace model-load barrier with chained base::OneShotEvents
Two signals gate the EmbeddingGemma model load: the component being
installed and the renderer-side PassageEmbedderFactory registering. A
BarrierClosure(2) paired with a component_ready_counted_ flag was
needed because LocalModelsUpdaterState::AddObserver synchronously
re-fires OnLocalModelsReady when install_dir is already set, which
would otherwise tick the barrier twice.
Swap the barrier for two base::OneShotEvents: Signal() is idempotent
under is_signaled(), so the guard flag disappears, and chaining
Post(component_ready)->Post(factory_registered)->LoadLocalModelFiles
expresses the dependency directly.
Addresses:
https://github.com/brave/brave-core/pull/32689#discussion_r3114239143https://github.com/brave/brave-core/pull/32689#discussion_r3113758418
* Use state machine
---------
Co-authored-by: Brian Johnson <34129+bridiver@users.noreply.github.com>
HorizontalTabStripRegionView::UpdateButtonBorders() applies asymmetric
vertical border insets to the new tab button (top > bottom) so the
button's hit area extends to the top of the tab strip. This asymmetry
was introduced in #35778. The upstream ControlButtonHighlightPathGenerator
uses GetContentsBounds() for the hover highlight rect, which is shifted
down by the top inset. However, LabelButton centers its icon within
GetLocalBounds() (ignoring vertical insets), so the highlight and the
icon end up on different vertical centers.
Fix by installing a BraveNewTabButtonHighlightPathGenerator that takes
the highlight rect size from GetContentsBounds() but re-centers it on
GetLocalBounds().CenterPoint(), matching where the icon is drawn.
TEST=BraveNewTabButtonHighlightTest.HighlightVerticalCenterMatchesIcon
Resolvesbrave/brave-browser#55252
Follow-up to #35813 / brave-browser#54798. The previous PR removed the
WebUI feedback buttons on chrome://history and the side panel, but the
native Views omnibox still surfaced thumbs up/down on HISTORY_EMBEDDINGS
matches when the user typed `@history`
(brave-browser#55178).
- Plaster `OmniboxPopupSelection::IsControlPresentOnMatch` to inject a
short-circuit `if ((true)) return false;` immediately after the
FOCUSED_BUTTON_THUMBS_UP / FOCUSED_BUTTON_THUMBS_DOWN case labels.
Matching only the case labels (not the existing return expression)
keeps the plaster resilient if Chromium tweaks the body. With these
selections never available, OmniboxResultView::
UpdateFeedbackButtonsVisibility keeps the buttons hidden, keyboard
traversal skips them, and the feedback page is unreachable from the
omnibox.
- Combine the existing featured_search_provider.cc IDS swap with a
drop of the upstream `+ u" "` separator in a single substitution.
With the link text already swapped to IDS_BRAVE_EMPTY_STRING in
#35813, that separator left match.contents with a trailing space
that tripped the AutocompleteMatch::SanitizeString DCHECK in
AutocompleteResult::AppendMatches.
Reject duplicate RegisterPassageEmbedderFactory
mojo::Remote::Bind CHECKs when called on an already-bound remote, so a
buggy or compromised renderer that calls RegisterPassageEmbedderFactory
twice without first triggering a disconnect would crash the browser.
Ignore the duplicate registration so the second call is a no-op. The
renderer-reload path is unaffected: disconnect resets factory_ via
OnFactoryDisconnected before the renderer re-registers.
The patching machinery in Brave usually creates patches with the
equivalent of:
```
git -C .. diff --src-prefix=a/ --dst-prefix=b/ --default-prefix --full-index --ignore-space-at-eol browser/foo.cc
```
This is not enforced officially, and every now and then someone
generates patches manually and gets them merged with some other type of
header, which ends up causing issues when syncing, or using other types
of tooling that assume certain expectations from these patches. This PR
prevents that.
Another check being added is to validate that a patch added to this path
always have one file only in it, as this is an invariant of our patching
system.
Resolves https://github.com/brave/brave-browser/issues/55231
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 2: vendored crates that BoringTun depends on, plus some
ignore rules for linters to make sure builds are not broken;
following the similar ignores for wasm. There is also a
Cargo.lock file with the list of the dependencies and versions.
All the vendored crates were created by running `cargo vendor`;
the source files of the crates are unmodified, and DO NOT NEED
any manual review.
This changes the reader mode scripts to send only the actual meta tag content to the browser so that the tag can be constructed securely during reader mode page construction rather than copied in as-is.
Brian Johnson