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.
* Fix caption button overlap with toolbar in vertical tabs Qt theme
When vertical tabs with hidden title bar is enabled, window control
buttons overlapped the toolbar on Linux with the Qt theme. GTK theme
worked correctly.
The root cause was in GetLeadingTrailingCaptionButtonWidth(): it
branched on UsingSystemTheme() which returns true for both GTK and
Qt. The GTK path cast the frame view to BraveBrowserFrameViewLinuxNative
to read actual button bounds. However, Qt doesn't use the native
frame view (QtUi::CreateNavButtonProvider() returns nullptr),
so the cast failed silently and returned zero-width exclusions,
causing overlap.
Replace the custom GetLeadingTrailingCaptionButtonWidth() with
upstream Chromium's BrowserFrameView::GetBrowserLayoutParams(),
which reads actual button positions post-layout from whichever frame
view is active. This works correctly for GTK, Qt, Classic, Windows,
and macOS without platform-specific branching.
Also add a Layout(PassKey) override in BraveOpaqueBrowserFrameView
to call UpdateHorizontalPadding() after buttons are positioned,
fixing the overlap that occurred after theme switches before the
next manual window resize.
Resolvesbrave/brave-browser#54471
This change moves the script used to generate the rust WASM toolchain
under `tools/cr/toolchains`, as tooling packaging is a Chromium rebase
concern, and it is better kept under the rebase's team purview. A
separate PR has been submitted to fix CI.
This PR is pretty much just a rearranging of code, with no practical
function changes. Files have been renamed to be less repetitive and more
intuitive. There are few minor changes though:
1. `_boot.py` has been introduced to allow `alias/` sources to be able
to include `tools/cr` into path and make themselves a submodule. This
is not the best posssible solution, but it does avoid having to mess
with PATH or PYTHONPATH and any other similar constant before calling
these scripts.
2. `PRESUBMIT.py` has been updated to run tests in subdirectories.
* Display runtime containers in the context menu where applicable.
* Add a comment to bookmark menu delegate.
* Migrate ContainersBookmarkMenuModelDelegate to BWI.
BraveOpaqueBrowserFrameView::GetTopAreaHeight() was changed in
99c6215 to use tabs::GetHorizontalTabControlsDelta() (-4 in default
mode, -5 in compact) instead of kTabstripToolbarOverlap (1 in default,
8 in compact). Subtracting a negative value adds to the height, so the
tab strip grew from 41px to 45px (default) instead of shrinking.
The fix reverts GetTopAreaHeight() to delegate to the upstream
OpaqueBrowserFrameView::GetTopAreaHeight(), which already picks up
Brave's kTabstripToolbarOverlap override via GetBraveLayoutConstant()
and handles both default and compact modes correctly.
Adds a parameterized browser test covering default and compact modes
that asserts the rendered tab strip height matches kTabStripHeight and
that the toolbar is positioned correctly relative to the tab strip.
TEST=BraveBrowserFrameViewTabStripHeightTest
This PR adds integration for `plaster` into `brockit`. This involves
primarily changes to how 3way apply works. With this change, whenever
3way apply fails due to conflicts or a broken patch, we take a next step
attempting to fix the issue by rerunning the plaster.
Why not rerun plaster always for any patch managed with a plaster?
It is important to maintain changes in a granular state that they can be
inspected. We don't want to do blanket `plaster` runs because that may
create a huge committable change, that would be harder to inspect and
specially harder to catch unintended plaster new interpretations based
in underlying Chromium changes.
This PR introduces a two step process for plaster:
1. The plaster re-run commit.
This commit is similar to the use of `Conflict-resolved` commits. It
will be commited with a message:
```
Regen-fixed 🩹 patches from Chromium VERSION to VERSION
```
This will be a pinned commit, and it will helps keep track of the
patches that did require a `plaster` rerun to apply again. This commit
follows the same rules of the `Conflict-Resolved` commit when it comes
to fixups for changes touching the patching in the same dev cycle.
2. The introduction of `plaster check`
At the end of the lift, we run `plaster check`. For the vast majority of
the cases, what the plaster rerun would have generated is exactly what
we got with simply reapplying the patch. However, for cases where the
patch re-applied, and yet a plaster re-run would somehow produce
something different, we want to alert about that, and have that
investigated, and committed with a culprit, to make such a change
visible during review.
It is important to notice that `plaster check` also runs during the
`presubmit` step, so even if not caught at this stage, it would be
brought to someone's attention at some point.
- Broken plasters
A new section in the continuation report has been added for broken
plasters, which are required to be either fixed or deleted before
calling `--continue`.
Resolves https://github.com/brave/brave-browser/issues/55188
The icon_suffix lookup in get_icon_artifacts() only matched
branding == "brave", so Brave Origin packages always staged the
stable product_logo PNGs regardless of channel. Brave Origin nightly
ended up registering the stable Origin icon under the
brave-origin-nightly icon name, making nightly indistinguishable
from stable in desktop environments.
Fixbrave/brave-browser#54734
StephenHeaps