Chromium changes:
https://chromium.googlesource.com/chromium/src/+/01ff99168958e53d2a5a0e7bef3e14d13cbcfe96
commit 01ff99168958e53d2a5a0e7bef3e14d13cbcfe96
Author: Thomas Lukaszewicz <tluk@chromium.org>
Date: Sun Apr 19 17:11:57 2026 -0700
Simplify DevtoolsUIController
DevtoolsUIController::UpdateDevtools is updated to only take the
target web contents - instead of the container view and web contents.
The implementation assumes that the container view was the host of
web contents, however this can be easily resolved from just the
web contents itself within the DevtoolsUIController and mitigates
the risk of the params drifting.
Removes a DeprecatedLayoutImmediately() call from
BrowserView::UpdateDevTools() which has been in the codebase since
2009 and is no longer necessary. Instead layout is invalidated if
necessary.
Note: DevtoolsUIController::UpdateDevTools() still needs to return
whether a layout is required as BrowserView may need to perform
a synchronous layout operation separately from marking the layout
as invalid.
Bug: 502745808
Change-Id: I627a45dca0c975a5d422b2aedfa75bd4de8134a2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7766514
Reviewed-by: Darryl James <dljames@chromium.org>
Commit-Queue: Thomas Lukaszewicz <tluk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1617272}
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/6c9ccc1c9d53aee2a221dc37dab54b167fb3e09c
commit 6c9ccc1c9d53aee2a221dc37dab54b167fb3e09c
Author: Russ Hamilton <behamilton@google.com>
Date: Fri Apr 17 09:50:05 2026 -0700
[WebUI Avatar] Migrate callers to AvatarToolbarButtonInterface
This CL migrates all usages of
ToolbarButtonProvider::GetAvatarToolbarButton() to use
GetAvatarToolbarButtonInterface() instead. This is part of the effort to
make toolbar components framework-agnostic and support both Views and
WebUI implementations of the avatar button.
- Remove the deprecated GetAvatarToolbarButton() method from the
ToolbarButtonProvider interface.
- Remove implementations of GetAvatarToolbarButton() in ToolbarView
and WebAppFrameToolbarView.
- Migrate all production and test callers to use the interface and its
framework-agnostic methods.
- Update includes across the codebase to prefer
avatar_toolbar_button_interface.h over avatar_toolbar_button.h where
the concrete type is no longer needed.
Bug: 470045174
Change-Id: Iff0147b3ba6eb354a893115be873eb27808150f8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7727070
Reviewed-by: Ryan Sultanem <rsult@google.com>
Auto-Submit: Russ Hamilton <behamilton@google.com>
Commit-Queue: Russ Hamilton <behamilton@google.com>
Cr-Commit-Position: refs/heads/main@{#1616641}
With this CL moving things around, this has caused a lot small issues
in several places where unwanted replecaments started to occur, or other
types of failures, like name collision.
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/e0f759f728337f7df2f808ebc2c1eefffab5c5e3
commit e0f759f728337f7df2f808ebc2c1eefffab5c5e3
Author: Athul Iddya <athul@iddya.com>
Date: Thu Apr 16 17:08:08 2026 -0700
Add a native frame view for non-browser widgets on Linux
Introduces NativeFrameViewLinux, a FrameViewLinux subclass that provides
native client-side decorations for non-browser widgets on Linux. This
class is preferred over FrameViewLinux for the GTK UI theme. Its
implementation mirrors BrowserFrameViewLinuxNative, using
WindowFrameProvider for frame decoration and NavButtonProvider for
window control buttons.
NativeFrameViewLayoutLinux similarly extends FrameViewLayoutLinux to
override frame and button layout decisions using WindowFrameProvider and
NavButtonProvider. Shared utilities between NativeFrameViewLinux and
BrowserFrameViewLinuxNative are extracted into frame_view_utils_linux.
WindowFrameProvider and NativeTheme gain options for non-browser frame
rendering: top area height, padding and border APIs, and bottom border
drawing in the top area, to match the appearance of native GTK dialogs.
Bug: 396190939
Cq-Include-Trybots: luci.chromium.try:linux-wayland-mutter-rel,linux-wayland-weston-rel
Change-Id: Iee94d493a1751176c38d793e7efcfe47271bc909
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7615475
Commit-Queue: Thomas Anderson <thomasanderson@chromium.org>
Reviewed-by: Thomas Anderson <thomasanderson@chromium.org>
Auto-Submit: Athul Iddya <athul@iddya.com>
Reviewed-by: David Yeung <dayeung@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1616203}
`ChromeUpdateClientConfig` has dropped the `url_override` arg. Th change
also removes an unnecessary patch for `ChromeUpdateClientConfig` which
was causing issues.
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/e585ba13ce9ed5667530a315850713c1eeb3cd20
commit e585ba13ce9ed5667530a315850713c1eeb3cd20
Author: Joshua Pawlicki <waffles@chromium.org>
Date: Fri Apr 17 07:58:49 2026 -0700
extension updater: Use update_client updater for sync/policy installs
Previously, the first install of an extension (when driven by sync or
policy) would still default to using the old extension update stack.
This isn't necessary; the new stack can be used in this case.
This relands
https://chromium-review.googlesource.com/c/chromium/src/+/7545510
The original CL is patchset 1. Since then,
ExternalProviderImplTest.InAppPayments (which isn't covered by CQ)
is fixed, which was unfortunately a bigger job than I hoped.
Fixed: 482088398, 500551122
Change-Id: Iee3d224770896f5abc288d1facbd492f67ef9554
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7769170
Reviewed-by: Owen Min <zmin@chromium.org>
Auto-Submit: Joshua Pawlicki <waffles@chromium.org>
Commit-Queue: Joshua Pawlicki <waffles@chromium.org>
Reviewed-by: Devlin Cronin <rdevlin.cronin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1616564}
These features were moved under common
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/3fe669867f71303e859e010511f565c174eff5ff
commit 3fe669867f71303e859e010511f565c174eff5ff
Author: Thomas Lottermann <lottermann@google.com>
Date: Wed Apr 8 02:25:11 2026 -0700
[OTP] Make One Time Token service URL configurable via FeatureParam.
This change replaces the hardcoded URL for fetching email one-time
tokens with a FeatureParam, allowing the service URL to be modified
through Finch. The default value of the FeatureParam is set to the
original URL.
Bug: b:478840986
Fixed: b:478840986
Change-Id: I7e0f0a48c1d8fd735d451fc741635a5cfc4460ee
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7711420
Commit-Queue: Thomas Lottermann <lottermann@google.com>
Reviewed-by: Matthias Körber <koerber@google.com>
Reviewed-by: Trang Mai <trangm@google.com>
Cr-Commit-Position: refs/heads/main@{#1611334}
The accessor is now gone, and `BrowserView::GetBrowserViewForBrowser` is
used in its place.
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/aaed67f345e86a74c60a9f666cd19fe898d23605
commit aaed67f345e86a74c60a9f666cd19fe898d23605
Author: Thomas Lukaszewicz <tluk@chromium.org>
Date: Wed Apr 15 11:32:42 2026 -0700
[bedrock] Move bookmark-related methods to BookmarkBarController
This CL re-homes bookmark-related methods on BrowserWindow to the
BookmarkBarController browser window feature. Test-specific methods
that only have a BrowserView impl have been removed and test code
updated to check the BrowserView directly.
This is part of an effort to slim BrowserWindow and better modularize
browser feature code.
Bug: 502745808
Change-Id: I4046786862ff822a6a11c278e25948f478340aa2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7763260
Reviewed-by: David Yeung <dayeung@chromium.org>
Commit-Queue: Thomas Lukaszewicz <tluk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1615305}
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/4650246ccb09055bd278e075fb26055343174087https://chromium.googlesource.com/chromium/src/+/830564b5f14f755a81fa9f9d5f1e171b568dfc6a
commit 4650246ccb09055bd278e075fb26055343174087
Author: Kun Wang <kunwang@microsoft.com>
Date: Tue Apr 14 20:46:35 2026 -0700
[bedrock] Remove FindAllTabbedBrowsersWithProfile() from BrowserFinder
Bug: 494010890
Change-Id: I7d237edf67693e11d23397813f06d4e32d27d5a4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7738568
Reviewed-by: Thomas Lukaszewicz <tluk@chromium.org>
Reviewed-by: Qikai Zhong <qikaizhong@microsoft.com>
Commit-Queue: Kun Wang <kunwang@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1614924}
commit 830564b5f14f755a81fa9f9d5f1e171b568dfc6a
Author: Yu He <yhe@microsoft.com>
Date: Thu Mar 19 12:08:13 2026 -0700
Reland "[bedrock] FindAllTabbedBrowsersWithProfile() function call point refactoring"
This is a reland of commit e1e46c26f73c2b52e384e7ea0b59d312ab6399c5
The original CL was reverted because it caused
ActorLoadAndExtractContentToolBrowserTest.WindowClosedPrematurely to
fail on linux-wayland-mutter-rel-tests.
Root cause: GetActiveWindowId() used ProfileBrowserCollection::ForEach()
with the default kCreation order. On Wayland, when a new browser window
is shown via BrowserView::Show(), DidBecomeActive() is called
synchronously for the new window, but DidBecomeInactive() for the
previous window only fires asynchronously when the compositor sends a
"lost focus" event. This means both windows can have IsActive()==true
simultaneously. With kCreation order, the older (wrong) window was found
first. The original FindAllTabbedBrowsersWithProfile() iterated in
activation order, so the most recently shown window was always checked
first.
Fix: Pass BrowserCollection::Order::kActivation to ForEach() in
GetActiveWindowId() to match the original iteration order.
Also re-enables the WindowClosedPrematurely test on Linux, which was
disabled by a gardener after the original CL landed.
Patchset 3 fixes the issue and has been verified locally by running the
test 50 times under mutter/Wayland without failure.
Original change's description:
> [bedrock] FindAllTabbedBrowsersWithProfile() function call point refactoring
>
> Migrate all non-test call sites of FindAllTabbedBrowsersWithProfile()
> from Browser* to BrowserWindowInterface*, adapting downstream method
> calls accordingly.
>
> Call sites migrated:
> - actor_proto_conversion.cc: session_id() → GetSessionID()
> - load_and_extract_content_tool_request.cc: session_id() → GetSessionID()
> - tab_sensitivity_cache.cc: tab_strip_model() → GetTabStripModel()
>
> The function still returns std::vector<Browser*>; each call site uses
> BrowserWindowInterface* as the range-based for loop variable, relying
> on the implicit upcast from Browser* to BrowserWindowInterface*.
>
> Bug: 431671320
> Change-Id: Ie621746798e54642981b5d2330a653a5f2501821
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7665417
> Auto-Submit: Yu He <yhe@microsoft.com>
> Reviewed-by: Qikai Zhong <qikaizhong@microsoft.com>
> Reviewed-by: Tom Lukaszewicz <tluk@chromium.org>
> Commit-Queue: Qikai Zhong <qikaizhong@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#1600308}
Bug: 431671320
Change-Id: I35bd2cc00fc4411c61570be4b906dc3b4dab5dba
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7678191
Reviewed-by: Qikai Zhong <qikaizhong@microsoft.com>
Commit-Queue: Tom Lukaszewicz <tluk@chromium.org>
Reviewed-by: Tom Lukaszewicz <tluk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1602148}
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/c93c5d88e4f60a6586e10ff1ce4a8feeaf3f4248
commit c93c5d88e4f60a6586e10ff1ce4a8feeaf3f4248
Author: Chris Fredrickson <cfredric@chromium.org>
Date: Wed Apr 15 12:37:06 2026 -0700
Add LoadAndExtractContent's tabs to ActorTask's tab set
This ensures that LoadAndExtractContent does not bypass the enterprise
policy blocklist, sensitive site list, or static navigation blocklist.
This CL also adds the ability to add a tab to the controlled tabs set
without stopping the ActorTask when that tab is detached/closed. This is
needed for the ephemeral tabs created by the LoadAndExtractContent tool.
Fixed: 497342466
Change-Id: I355e2bc4ab9a27d52281de10ce6bdc98b50cc43a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7727485
Reviewed-by: Jeremy Roman <jbroman@chromium.org>
Auto-Submit: Chris Fredrickson <cfredric@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Chris Fredrickson <cfredric@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1615339}
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/8f97262a2cc5aa37fcd710c3c141eb7f08c01f92
commit 8f97262a2cc5aa37fcd710c3c141eb7f08c01f92
Author: dpapad <dpapad@chromium.org>
Date: Wed Apr 15 15:03:48 2026 -0700
WebUI: Enable @typescript-eslint/no-explicit-any where possible.
Since there are too many violations across the codebase, enabling this
check by default will take a while. Instead of waiting until all
violations are fixed before the check is enabled anywhere, enabling it
for all targets that already don't exhibit any violations.
As the remaining offending targets are fixed they will be removed from
the exception list to ensure they can no longer regress after being
fixed.
The new check is skipped on Ash-only WebUI targets for now.
Bug: 494464740
Change-Id: Iadaa8718b1bb6e0188b80615cf2aff4ec3193588
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7763564
Reviewed-by: John Lee <johntlee@chromium.org>
Commit-Queue: Demetrios Papadopoulos <dpapad@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1615435}
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/98defbb5fe4cd74acc53e9f8d3b3ad9443adda65
commit 98defbb5fe4cd74acc53e9f8d3b3ad9443adda65
Author: Kent Tamura <tkent@chromium.org>
Date: Wed Apr 15 01:28:25 2026 -0700
Reland "Remove blink::WebString::FromUTF8()"
This is a reland of commit 64bea51a34e9a0f68769c2275e939d986f918495
Differences from the original commit:
Update `FromUTF8()` in the following files too:
* chromecast/renderer/activity_filtering_websocket_handshake_throttle.cc
* components/translate/content/renderer/translate_agent.cc
* third_party/blink/renderer/core/script_tools/model_context_test.cc
Original change's description:
> Remove blink::WebString::FromUTF8()
>
> We prefer FromUtf8().
> This CL has no behavior changes.
>
> Bug: 492927412
> Change-Id: I3976e85012e2189dd4377a7cd49148771970d158
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7760402
> Commit-Queue: Fredrik Söderquist <fs@opera.com>
> Owners-Override: Kent Tamura <tkent@chromium.org>
> Auto-Submit: Kent Tamura <tkent@chromium.org>
> Reviewed-by: Fredrik Söderquist <fs@opera.com>
> Cr-Commit-Position: refs/heads/main@{#1614316}
Bug: 492927412
Change-Id: I36fa1420e10759ad581bf8d2ccf7552831e10205
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7760406
Reviewed-by: Fredrik Söderquist <fs@opera.com>
Commit-Queue: Kent Tamura <tkent@chromium.org>
Commit-Queue: Fredrik Söderquist <fs@opera.com>
Owners-Override: Kent Tamura <tkent@chromium.org>
Auto-Submit: Kent Tamura <tkent@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1614993}
Due to transient header inclusions and with `Init` being a common token,
we've got another unwanted substitution which this preemptive header
inclusion prevents.
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/979202122d8d2ae3fffd4ffc027bdb86b78b7232
commit 979202122d8d2ae3fffd4ffc027bdb86b78b7232
Author: Qingxin Wu <qingxinwu@google.com>
Date: Tue Apr 14 05:40:00 2026 -0700
[WebUI LLBC] Introduce PermissionChip Interfaces.
This CL is Phase 1 of decoupling the Left-Hand Side (LHS) location bar
chips from native Views, preparing for a WebUI implementation.
It introduces an abstract interfaces: `PermissionChipInterface`.
The native `PermissionChipView` now inherit from this interface. C++
controllers (`ChipController` and `PermissionDashboardController`) have
been refactored to hold pointers to the interfaces rather than concrete
View classes.
Bug: 495419742
Change-Id: I8451110f6c28d267528fa8ed2ead22dbb485e0a9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7705932
Reviewed-by: Maks Orlovich <morlovich@chromium.org>
Reviewed-by: Paul Jensen <pauljensen@chromium.org>
Reviewed-by: Elias Klim <elklm@chromium.org>
Reviewed-by: Thomas Lukaszewicz <tluk@chromium.org>
Commit-Queue: Qingxin Wu <qingxinwu@google.com>
Cr-Commit-Position: refs/heads/main@{#1614388}
We are now accessing this value through a private accessor with the
parent class.
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/0800caaa61eb1b551c622e41025def941ea6f0c9
commit 0800caaa61eb1b551c622e41025def941ea6f0c9
Author: Youssef Bourouphael <ybourouphael@google.com>
Date: Tue Apr 14 06:30:17 2026 -0700
Refactor: Extract AppMenuControl interface
This change extracts the core functionalities of the app menu button
into a new `AppMenuControl` interface.
- Introduced `AppMenuControl` interface defining methods to interact with the app menu button.
- Updated `AppMenuButton` to implement the new `AppMenuControl` interface.
- Modified `ToolbarButtonProvider` to expose the `AppMenuControl` interface instead of directly returning `AppMenuButton`.
- Migrated all call sites that previously accessed `AppMenuButton` directly to use the `AppMenuControl` interface.
- Updated bubble anchoring logic to utilize `views::BubbleAnchor`, allowing for more flexible anchoring options.
- Many existing calls to `GetAppMenuButton()` were migrated to use `views::ElementTrackerViews` to get the button view.
This refactoring is a prerequisite for future work on a Web UI version
of the app menu.
Bug: 470045312
Change-Id: I01d722ad76687e0f1e409f04a4feef4d0386540e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7722207
Reviewed-by: Paul Jensen <pauljensen@chromium.org>
Reviewed-by: Eshwar Stalin <estalin@chromium.org>
Commit-Queue: Youseff Bourouphel <ybourouphael@google.com>
Cr-Commit-Position: refs/heads/main@{#1614401}
This change only removes a inclusion to the header for this class that
was left behind in our code.
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/dd0cca1d9573996058b06159d99ef55904eae2a0
commit dd0cca1d9573996058b06159d99ef55904eae2a0
Author: Tiago Vignatti <tvignatti@igalia.com>
Date: Mon Apr 13 05:30:29 2026 -0700
Remove deprecated TestBrowserClosedWaiter
Delete TestBrowserClosedWaiter and migrate all callers to use
ui_test_utils::BrowserDestroyedObserver directly, as the class
was already marked deprecated. The ASSERT_TRUE wrappers around
WaitUntilClosed() are dropped since it unconditionally returned
true.
This also removes the circular dependency between
//chrome/browser/ui/test:closed_waiter and
//chrome/test:test_support_ui.
Bug: 353332589
Change-Id: I2685dba2a589870fcf1e6639f511932b2a051178
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7706499
Reviewed-by: Darryl James <dljames@chromium.org>
Commit-Queue: Tiago Vignatti <tvignatti@igalia.com>
Cr-Commit-Position: refs/heads/main@{#1613640}
This function has been replaced with a more accurately named one,
`GetIndexOfExistingTabMatchingURL`, which has been declared in a
different header.
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/3d5e08bc7b5649ff297b7a4026224b1040328de5
commit 3d5e08bc7b5649ff297b7a4026224b1040328de5
Author: Jack Thiesen <jthiesen@chromium.org>
Date: Mon Apr 13 13:14:15 2026 -0700
Move Navigation Helpers to Shared Location
WML's Navigate() implementation relies on helpers inside of
singleton_tabs.h that are not strictly used for singleton tabs and are
not used by other code. This change updates these helpers to use
platform-agnostic abstractions and moves them to a location that allows
for easy sharing between platforms. New unit tests are added.
Bug: 469764907
Change-Id: I7f503ea505adc480037e363abe8534f38e7c8d7b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7747634
Commit-Queue: Jack Thiesen <jthiesen@chromium.org>
Reviewed-by: Elly <ellyjones@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1613927}
All the fixes in this change are cases where we are converting a
property to a function as more appropriate.
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/9d25d0387044e57a67892521a2863a87c31b9cc9
commit 9d25d0387044e57a67892521a2863a87c31b9cc9
Author: rbpotter <rbpotter@chromium.org>
Date: Thu Apr 9 23:38:18 2026 -0700
WebUI: Validate that properties referenced in Lit template are reactive
Adding an automated check to ensure that if a class property
"this.someProp" is referenced in the HTML template, it is also properly
declared as a reactive property so that Lit will re-render the element
correctly when it changes.
Bug: 500066216
Change-Id: Ieb9989fc672d03cb2b20f2bd43301a688b42f270
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7731479
Commit-Queue: Rebekah Potter <rbpotter@chromium.org>
Reviewed-by: Demetrios Papadopoulos <dpapad@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1612640}
Recent changes in upstream have changed the tabulation. Although this
has not caused any conflict when applying patches, this change updates
the plaster to better reflect the current desired patching.
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/39f1fc11de89a81d446d6ee520973294a4023254
commit 39f1fc11de89a81d446d6ee520973294a4023254
Author: Ian Wells <iwells@chromium.org>
Date: Tue Apr 7 09:48:58 2026 -0700
Add contextual cueing v2 page action
Contextual cueing v2 will show cues for a few different features, so
while the page action is registered with the other browser actions, its
icon, anchored message details and click handler aren't set until it's
time to show a cue for a specific feature.
Bug: 497231692
Change-Id: I641e13d43661806a64759018a837f6fe316bfaac
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7732046
Reviewed-by: Charlie Harrison <csharrison@chromium.org>
Reviewed-by: Sophie Chang <sophiechang@chromium.org>
Commit-Queue: Ian Wells <iwells@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1610829}
This change updades our checker to use the newer version and keeps a
nullified implementation for the new method added to this new class.
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/75b2acce79497326ac3388f8d3e6d03a21b1459e
commit 75b2acce79497326ac3388f8d3e6d03a21b1459e
Author: Haihan Chen <haihan@google.com>
Date: Thu Apr 9 08:57:26 2026 -0700
[GLIC CEP Paste Support] Merge actor enterprise checks into single `EnterprisePolicyChecker` interface
To simplify the API and avoid extra param for actor tasks for content
policy checks specifically, since glic is the only user and implements
both url and content checks in a single class right now
(`glicactorpolicychecker`).
This is a refactor, content validation usage in tools like `PageTool` in
follow-up CL.
Bug: 473047343
Change-Id: I8fb9b45955ccff15c3331af445df05dfcc589ac4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7735646
Reviewed-by: Kevin McNee <mcnee@chromium.org>
Commit-Queue: Haihan Chen <haihan@google.com>
Cr-Commit-Position: refs/heads/main@{#1612275}
This the componentisation of these files, we do not need anymore to
include these sources ourselves in `brave_browser_tests`.
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/e0cd9afb25e911c62c8c096ef55816bd9e3b665e
commit e0cd9afb25e911c62c8c096ef55816bd9e3b665e
Author: Tiago Vignatti <tvignatti@igalia.com>
Date: Thu Apr 9 07:28:31 2026 -0700
Componentize chrome/browser/ui/test/
This changes create chrome/browser/ui/test/BUILD.gn with dedicated
targets for all test files in this directory, which were previously
scattered across chrome/test/BUILD.gn and chrome/browser/ui/BUILD.gn.
Some of the files were duplicated in multiple targets, and has now
fixed.
New targets:
- :dialog — moved from //chrome/test:test_support and de-duplicated from
browser_tests/interactive_ui_tests
- :closed_waiter — moved from //chrome/test:test_support_ui
- :test_support — de-duplicated and moved from browser_tests,
interactive_ui_tests, and //chrome/browser/ui:test_support
- :confirm_bubble — moved from //chrome/browser/ui:test_support
- :browser_tests — browser test files
- :interactive_ui_tests — interactive UI test files
- :app_window — moved from //chrome/browser/ui:test_support
Bug: 353332589
Change-Id: I602615d0b8a96af88af82cf1caaf75a3a2184d07
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7704138
Reviewed-by: Darryl James <dljames@chromium.org>
Commit-Queue: Tiago Vignatti <tvignatti@igalia.com>
Cr-Commit-Position: refs/heads/main@{#1612208}
This recent change requires us to fix our own overrides and callers for
these functions.
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/1575bebcd1c16fa1508c87eda06c5b3b1c364c3c
commit 1575bebcd1c16fa1508c87eda06c5b3b1c364c3c
Author: Duncan Mercer <mercerd@google.com>
Date: Wed Apr 8 15:31:53 2026 -0700
[Blink/Network] Support origin targeting for secure exemptions
This change updates WebSecurityPolicy to support origin targeting
for secure embedder exceptions by allowing specific origins instead
of applying globally to an entire scheme.
It also migrates secure cookie exemptions—specifically those affecting
third-party cookie blocking and SameSite restrictions—in CookieManager
and CookieSettings from scheme/host-based registration to
url::Origin-based registration. This enables precise, unscoped
exemptions for secure origins (such as chrome-untrusted://lens)
without modifying the properties or behavior of the cookie origin
itself.
Bug: b:483614998
Change-Id: I7fe2a00e631513c6ebcdb5fb996914f5b48a9447
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7689068
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Nidhi Jaju <nidhijaju@chromium.org>
Reviewed-by: Dylan Cutler <dylancutler@google.com>
Commit-Queue: Duncan Mercer <mercerd@google.com>
Reviewed-by: Joshua Hood <jdh@chromium.org>
Reviewed-by: Lily Chen <chlily@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1611822}
This change corrects several places to pass `TranslateUrlFetcher` into
`TranslateLanguageList`.
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/6aef37c345ee6449713a213c04878417dd87d0c4
commit 6aef37c345ee6449713a213c04878417dd87d0c4
Author: Danilo Françoso Tedeschi <danft@google.com>
Date: Wed Apr 8 06:26:11 2026 -0700
Replace static DisableUpdate with dependency injection for TranslateLanguageList.
This change removes the global static flag `update_is_disabled` from TranslateLanguageList and instead allows injecting a TranslateUrlFetcher instance. This improves testability by allowing mock fetchers to be used without relying on global state. TranslateDownloadManager now has a setter for its TranslateLanguageList.
Change-Id: I739659aba52e95e6236e0b5d85fd9672b090c864
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7719220
Reviewed-by: Basia Zimirska <basiaz@google.com>
Commit-Queue: Danilo Françoso Tedeschi <danft@google.com>
Cr-Commit-Position: refs/heads/main@{#1611437}
This used to be an alias to:
```cxx
using BubbleAnchor = std::variant<std::nullptr_t, View*, ui::TrackedElement*>;
```
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/1ba6a69579ba3b5f5925ff77a390be5a99d748e7
commit 1ba6a69579ba3b5f5925ff77a390be5a99d748e7
Author: Maks Orlovich <morlovich@chromium.org>
Date: Tue Apr 7 11:33:31 2026 -0700
Make BubbleAnchor an own class.
The variant implementation has a property that seems very unfortunate:
it has 3 possible places it can store nullptr, which makes it tricky to
reason about and work with, e.g.:
BubbleAnchor Foo() {
if (View* view = Bar()) {
return view;
}
return nullptr;
}
is not equivalent to: BubbleAnchor Foo() {
return Bar();
}
It's also somewhat awkward to use, and can't be forward declared.
The class wrapper normalizes the nulls. It also gives it is own
header (and can be forward declared).
Change-Id: I2aacb894ee995af7fd012f2762826cd30f277179
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7647509
Reviewed-by: Dana Fried <dfried@chromium.org>
Commit-Queue: Maks Orlovich <morlovich@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1610910}
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/ddd5ffe0ad3129bb03508ab864465e77f0e50bedhttps://chromium.googlesource.com/chromium/src/+/2174233eeebf04d1a671c66f2be7b630e6117de0
commit ddd5ffe0ad3129bb03508ab864465e77f0e50bed
Author: Yu He <yhe@microsoft.com>
Date: Wed Apr 8 12:02:16 2026 -0700
[bedrock] Remove unused chrome::FindAnyBrowser()
The FindAnyBrowser() function in browser_finder.h
is unused. Its declaration already carried a warning ("Do not use this
method"), and there are no remaining callers in the codebase.
Remove the declaration and definition to reduce dead code.
Bug: 494010890
Change-Id: Iec391a4c4f9001726daf4b350fc3e3eccafe9017
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7736509
Commit-Queue: Tom Lukaszewicz <tluk@chromium.org>
Auto-Submit: Yu He <yhe@microsoft.com>
Reviewed-by: Tom Lukaszewicz <tluk@chromium.org>
Reviewed-by: Qikai Zhong <qikaizhong@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1611701}
commit 2174233eeebf04d1a671c66f2be7b630e6117de0
Author: yhe <yhe@microsoft.com>
Date: Sun Mar 29 15:57:42 2026 -0700
[bedrock] Move FindAnyBrowser to ui_test_utils
Migrate chrome::FindAnyBrowser() into ui_test_utils::FindAnyBrowser(),
reimplementing it on top of GlobalBrowserCollection and
BrowserWindowInterface instead of the legacy Browser-based APIs.
The new helper:
- Returns BrowserWindowInterface* (instead of Browser*).
- Iterates browsers via GlobalBrowserCollection::ForEach() in
activation order.
- Skips delete-scheduled browsers.
- On ChromeOS, excludes windows shown on another user's desktop
via ash::MultiUserWindowManager.
- Defaults match_original_profiles to true (most callers used true).
Update all test call-sites to use the new function:
- session_login_browsertest.cc
- profile_window_browsertest.cc
- browser_finder_chromeos_browsertest.cc
- browser_finder_chromeos_unittest.cc
- toolbar_view_interactive_uitest.cc
Add the required BUILD.gn deps (//chrome/browser/ui/browser_window,
//chrome/browser/ui/ash/multi_user, //chrome/test:test_support_ui).
Bug: 494010890
Change-Id: I07701d0c20514e51ead54c3367ddfbb0317735a6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7686930
Reviewed-by: Qikai Zhong <qikaizhong@microsoft.com>
Reviewed-by: Tom Lukaszewicz <tluk@chromium.org>
Commit-Queue: Tom Lukaszewicz <tluk@chromium.org>
Auto-Submit: Yu He <yhe@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1606838}
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/57a7dfb4e2645b9c62d3a005436c815f4314b5e6https://chromium.googlesource.com/chromium/src/+/a65d0fd3d0c70c37e7ac03bbc7389961eb69e66d
commit 57a7dfb4e2645b9c62d3a005436c815f4314b5e6
Author: Daniel Cheng <dcheng@chromium.org>
Date: Tue Apr 7 01:29:42 2026 -0700
Remove base/logging.h include from validation_errors.h
This header is included in many C++ source files generated from .mojom
and is fairly heavyweight. While moving the logging out of the headers
is straightforward, array validation failures generate a std::string
with some runtime details. `std::string_view` handles both cases nicely,
but there is value in minimizing the includes in this file as much as
possible. `const char*` and using `.c_str()` was the initial approach
considered, but discarded as a bit too hacky after some prototyping.
Instead, the helpers that create additional context for array validation
failures now return a struct with details about the failure. The various
validation error reporting functions have additional overloads that
internally stringify the details so that validation errors are still
reported in the exact same way.
gemini-cli was used to quickly prototype some ideas as well as implement
the overall CL, with some manual followups to improve naming and reduce
duplication.
One unintended side effect is a minor improvement in binary size, since
the new error detail structs are trivially destructible, unlike
std::string.
Bug: 499476145
Change-Id: If52b10f4928b7920ea7b120754a1798c125fefa7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7730404
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1610607}
commit a65d0fd3d0c70c37e7ac03bbc7389961eb69e66d
Author: Daniel Cheng <dcheng@chromium.org>
Date: Tue Apr 7 01:23:35 2026 -0700
Fix several more IWYU errors for base/logging.h
Bug: 499476145
Change-Id: Iba431f2c534365f9ea575c9be86bd70e8fa6a268
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7732103
Owners-Override: Takuto Ikuta <tikuta@chromium.org>
Reviewed-by: Takuto Ikuta <tikuta@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Kouhei Ueno <kouhei@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1610606}
This feature was being disabled in Brave.
Chromium changes:
https://chromium.googlesource.com/chromium/src/+/d57f3260469cb57abc0109976110a760d30dcfbb
commit d57f3260469cb57abc0109976110a760d30dcfbb
Author: Andrew Paseltiner <apaseltiner@chromium.org>
Date: Wed Apr 8 14:15:25 2026 -0700
Remove experimental CSSSelectorFragmentAnchor feature
The CSSSelectorFragmentAnchor feature was an experimental extension to
fragment directives that has not seen active development in years and
has never been officially specified. Furthermore, the implementation
lacked certain security controls (crbug.com/497956094) discussed in the
feature proposal
(https://github.com/WICG/scroll-to-text-fragment/blob/main/EXTENSIONS.md#proposed-solution).
This CL removes the implementation, including:
- The CssSelectorFragmentAnchor and CssSelectorDirective classes.
- The CSSSelectorFragmentAnchor runtime-enabled feature flag.
- The -internal-selector-fragment-anchor pseudo-class.
- Associated UA styles and metrics.
The createSelectorDirective() JS API is preserved as it is used by the
Text Fragments feature to generate TextDirectives. Related WPTs are
updated to remove CssSelector specific tests while maintaining coverage
for general directive parsing.
Bug: 1253707, 40203851, 40203761, 497956094
Change-Id: I2b11bdbde4475e48693f182ecca3c0bf9c79c198
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7735903
Reviewed-by: Sebastien S-G <sebsg@chromium.org>
Commit-Queue: Andrew Paseltiner <apaseltiner@chromium.org>
Reviewed-by: Rick Byers <rbyers@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1611777}
This PR introduces the YAML frontend for plaster that is meant to
eventually become the only frontend, once all `.toml` Plaster files are
migrated.
This change covers all places where the assumption about `.toml` files
was being used, inclusing `brockit`, and `git-cr` tools.
Most of the code that should be deleted in the future is well guarded
with comments leading back to the issue tracking, so the TOML parser can
be dropped eventually.
With this change, a dependency to `pyyaml` has been introduced. This
dependency has wheels provided by `vpython`, which is already the
expected python runtime for Plaster.
- Rationale for this change
We have experimented at length with `.toml` files, in order to
understand some of the shortcomings they have that would be addressed
with `.yaml` files.
* `prettier` offers YAML formatting out-of-the-box. On the other hand,
formatters for TOML files are not easy to find, as both `prettier`
and `vpython` have their own challanges with the current options
* YAML's sytanx works better with codeblocks, as it doesn't require
quoting. This makes the content seen less noisy. Looking on some of
the migrated plasters, the YAML substitutions look more readable.
* YAML has better sytanx highlight support in some editors.
Bug: https://github.com/brave/brave-browser/issues/55738
This PR introduces some fallback parsing for `tomllib` use, when running
this script in a machine with a python version older than `3.11`. This
will be necessary for the time being with the Linux node still using
Python 3.10.
On Windows, we have to manually correct the default the `ar`
`config.toml` value to `llvm-ar.exe`, as Windows defaults as a normal
Windows build uses `llvm-lib.exe`.
On Windows, we need to make sure we are picking up the correct C
compiler for the WASM build, and as this value was not being provided in
the template, `clang-cl.exe` was being picked up.
This PR generates a fuller stanza in the template for the WASM build,
that replicates the host one, but makes sure to tweak this necessary
value for windows. It is also of notice that we keep the linker whatever
is the default to be picked up.
This PR changes how the checkout works in the rust toolchain WASM
builder, to avoid the use of `gclient sync -r {ref}`. It is not clear if
we are having issues with it exactly, but the Windows pipeline keeps
hanging, and this particular long standing `gclient` issue has caused
pipeline issues before.
This PR also follows up on the work done by the previous one, and
updates all the other scripts to output the `stderr` the same way the
rust builder is doing.
Bug: https://github.com/brave/brave-browser/issues/44921
[cr150][brockit] Fix handling of `fixup!` block messages
This PR fixes how we are handling the block messages for `fixup!`, as
the parsing for them was always assuming that they would receive the
label `will be skipped:` for not having any message in them, but
actually that doesn't appear to be the case with every `fixup!`. With
this change, `fixup!` blocks that have no message are now discarded too.
Bug: https://github.com/brave/brave-browser/issues/55466
This PR changes our `rebase --interactive` call to be use `terminal.run`
with `interactive=True`, so we don't capture the output of that command.
This will generate noise when running `brockit rebase`, however this is
necessary for the user to be able to use the editor opened due to
`EditorRecoverableFailure`.
There are also changes to `terminal`, to make sure we stop producing any
type of status update while `interactive=True` commands are ongoing.
Bug: https://github.com/brave/brave-browser/issues/55466
This PR changes the function we use to run commands in the rust builder
to always allow `stderr` through. We are also adding a log whenever the
script is launched to indicate the value of `GIT_CACHE_PATH`.
This PR introduces a check mechanism to `plaster` that will allow it by
default to just reapply patches when that's needed. This is being done
with a simple approach:
* Check if the `.patchinfo` timestamp older than the plaster file,
patch, or upstream source.
* If `.patchinfo` is newer than any of these, we go on to check if the
checksums are matching with what is in the `.patchinfo`.
* If any of the checksum chcks fail, we reapply the patch.
This is very lightweight, and will make most of the uses of `apply`
reliable for reruns while working on a feature.
Resolves https://github.com/brave/brave-browser/issues/45057
This fix corrects an issue that has been present in this builder all
along, where it locks onto whatever was the latest checkout version
after cloning, rather than the one we want to sync with.
With this change, the python rust modules are loaded only after the
checkout.
[cr150][plaster][android] Migrate `AUTOPLAY` patches
This PR migrates several java patches for `AUTOPLAY` to plaster. It uses
the same previous techniques, where we match the enum block and add at
the end.
The only innovation in this PR as an approach for plaster is the
replacement of the value `NUM_ENTRIES` with `+1` for whatever keys we
are inserting, while at the same time using the previous value of
`NUM_ENTRIES` as the starting value for the first key.
Resolved https://github.com/brave/brave-browser/issues/55385
This PR introduces the basic tooling to have `include-what-you-use` run
against the brave codebase in maintainance mode. This manual regular
runs that cover more and more of the codebase.
Bug: https://github.com/brave/brave-browser/issues/42212
This is a new `brockit` subcommand that takes care in creating the
commit updating the Xcode toolchain in brave-core.
```sh
brockit.py update-xcode-toolchain --culprit=[optional] <url>
```
The URL in question is printed by CI when generating a new toolchain,
with the label `Download URL: <url>`
Bug: https://github.com/brave/brave-browser/issues/55528
This PR moves to `chromium_src` code that can live in there, and does
with no need for `#define` macro uses. This keeps plaster files shorter,
which reduces the noise in them, and it also permits C++ code to live
in C++ sources, that can benefit from code formatting, and DEPS
validation.
This PR has combined runs of IWYU for for:
- `//components/brave_ads/browser`
This is being done in an experimental manner to acquire some experience
with this tooling.
Bug: https://github.com/brave/brave-browser/issues/42212
This is an experimental toolchain build for the Apple toolchain. It just
packs certain files in a single archive so we can use it during the
build in a particular place, preserve the hermetic aspect of it.
Naming convention for the toolchain file is being calculated now based
on the version we are upgrading to, and the version Chromium has been
upgraded to, so we have a better view of what the toolchain is. This
will allow toolchain update to be done by `brockit` automatically,
whenever the toolchain is available.
Bug: https://github.com/brave/brave-browser/issues/55528
The use of `bool` for `DeviceInfo` fields has led to bugs in the past.
This has been correct with plaster, however we should also convert the
field to an enum to make sure we follow the upstream practice of using
enums in this type.
Resolves https://github.com/brave/brave-browser/issues/55018
This PR corrects several of the dos-and-donts violations under
`tools/cr`. This is particularly useful to prevent future bugs with file
reads and writes that have been persistent from time to time.
This PR introduces the foundation for a new rebase routine to be used by
`brockit` when doing `brockit --rebase`. This routine is nearly feature
complete with the standard one, the only exception being the dropping of
support for `--recommit`, which was introduced but never really used in
CI.
This implementation aims at making the code around rebases cleaner, more
reliable, and easier to customise in the future. It is also already
taking steps towards us having an implementation for `--continue`
support.
An interesting feature this v2 code brings is taht when parsing
questions occur, we bubble up these issues to the use through exceptions
that launch the user editor to evaluate what's going on.
Bug: https://github.com/brave/brave-browser/issues/55466
This PR changes the way we are patching `RequestType` to not have to
rely on any particular key, but just introduce our keys at the end of
the enum value. This technique allows for the replacemnt of `kMaxValue
to use the new value we provide.
Removing these lines so we can introduce `count` value checks to steer
users towards fixed counts only when needed, and away from `count=0`. At
the moment removing these as they are redundant.
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 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
This change removes uses of `sys.exit(1)` and error message prints from
`PlasterFile`, as this interferes with other tools using this class,
like `cr-mv`, `cr-follow-renames`, and `brockit`.
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`.
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 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.
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
These are helpers for the rebase process, in particular involve file
renames. These helpers are supposed to be intuitive on their use. These
commands do something similar, and there's overlap between them, but
they are for different purposes.
What happens when you use `git cr mv`:
* Move source to destination
* Correct shadowed file inclusion for `chromium_src`
* Corrects header guards for the new path
* Corrects all references elsewhere for that file inclusion
* Deletes stale patches if moving plasters.
What happens when you use `git cr follow-renames`:
Follow renames has a narrow purpose of taking git changes, checking
which files got renamed, and moving only those particular files to a new
location. It will do nearly everything else identical to `git cr mv`.
Resolves https://github.com/brave/brave-browser/issues/55189
This PR rewrites our overrides relating to `DeviceInfo` specifically
into plaster. This involves dropping `BraveDeviceInfo` and implementing
the functionality in terms of extending `DeviceInfo`
Resolves https://github.com/brave/brave-browser/issues/55018
This change simplifies a lot of the code around `Patchfile`, but
expecting instances of `Patchfile` to be provided with the expected
`source` value for the source file to be patched. This eliminates a lot
of the creative ways how we were detecting that information.
We can use a single git call to retrieve the underlying source for all
patches, which this change does.
Additionally, there is some sprucing up of the codebase, to make
consitent uses of `Path`. The use of `PurePath` creates the need for a
lot of conversions, so we are making this more consistent.
Resolves https://github.com/brave/brave-browser/issues/55177
Claudio DeSouza