Claudio DeSouza
e337234585
Chromium changes: https://chromium.googlesource.com/chromium/src/+/413253d95c40cac909a41e7455aef781f55b6ca5 commit 413253d95c40cac909a41e7455aef781f55b6ca5 Author: Balazs Engedy <engedy@chromium.org> Date: Tue Feb 17 05:19:34 2026 -0800 Clean up allow/ask/block logic for category default settings. This CL refactors SettingsCategoryDefaultRadioGroupElement to directly handle ContentSetting values (ALLOW, ASK, BLOCK) instead of first mapping them to a binary ENABLED/DISABLED state. This makes the terminology cleaner, removes the built-in constraint that each setting is two-state, and that ENABLED always maps to either ALLOW or ASK. This is a pure refactoring without any changes to functionality or UI, except for one thing. The WebHID setting on chrome://settings/content now reads "Sites can ask to connect to HID devices" instead of the old "Ask when a site wants to access HID devices" phrasing which was an odd one out. In more detail: The custom element now contains three potential radio buttons (Allow, Ask, Block) and dynamically hides the ones for which no label is provided. While historically it contained: enabledRadioOption, and disabledRadioOption; now it always contains: allowRadioOption, askRadioOption, and blockRadioOption. In the current implementation, for each category type, exactly two of the three are shown, decided based on which radios the category-specific HTML files supplies labels for. E.g. the HTML would set `allowOptionLabel` and `blockOptionLabel` for an allow/block two-state setting, and leave `askOptionLabel` undefined. Technically three-state settings could be supported in the future, but we need to add more test coverage for that. This change snowballed into some larger mechanical renames, namely: -- Updated category-specific pages (e.g., microphone_page.html) for ask/block permissions to use the new `ask-option-label` attribute. -- Renamed IDS_SETTINGS_SITE_SETTINGS_..._ALLOWED strings to ..._ASK in `settings_strings.grdp` for categories where the language used on the UI actually was along the lines of "Sites can ask to access ...". This was the case for many permissions in the first half of the alphabet, e.g., Camera, Microphone, Geolocation; but not so much for permissions more recently added, such as Local Network, or Window Management. -- Updated site_settings_page.ts to reference the new ...Ask string names for the `enabledLabel` for IDS_ that were changed. -- Removed duplicate/unused HID device strings (IDS_SETTINGS_SITE_SETTINGS_HID_DEVICES_ALLOW and _BLOCK) and landed on _ASK and _BLOCKED for consistency. Bug: 40623130 Change-Id: I5110517a51d966db6d44bf73c477fb4580716ee0 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7581214 Reviewed-by: Rainhard Findling <rainhard@chromium.org> Commit-Queue: Balazs Engedy <engedy@chromium.org> Cr-Commit-Position: refs/heads/main@{#1585671}
Brave Core
Brave Core is a set of changes, APIs, and scripts used for customizing Chromium to make the Brave browser. Please also check https://github.com/brave/brave-browser which only holds the issues, releases and the wiki.
Overview
This repository holds the build tools needed to build the Brave desktop browser for all platforms. In particular, it fetches and syncs code from the projects defined in package.json and src/brave/DEPS:
- Chromium
- Fetches code via
depot_tools. - Sets the branch for Chromium (ex: 65.0.3325.181).
- Fetches code via
- brave-core
- Mounted at
src/brave. - Maintains patches for 3rd party Chromium code.
- Mounted at
- adblock-rust
- Implements Brave's adblock engine.
- Linked through brave/adblock-rust-ffi.
Resources
Downloads
You can visit our website to get the latest stable release.
Contributing
Please see the contributing guidelines.
Our Wiki also has some useful technical information, especially about setting the development environment.
Security Policy
Please see the security policy.
Community
Join the Q&A community if you'd like to get more involved with Brave. You can ask for help, discuss features you'd like to see, and a lot more. We'd love to have your help so that we can continue improving Brave.
You can also ask questions and interact in the community-guest channel on Brave Software's Slack.
Help us translate Brave to your language by submitting translations at https://explore.transifex.com/brave/brave_en/.
Follow @brave on X for important news and announcements.
Install prerequisites
Follow the instructions for your platform:
Clone and initialize
Once you have the prerequisites installed, you can get the code and initialize the build environment.
git clone git@github.com:brave/brave-core.git path-to-your-project-folder/src/brave
cd path-to-your-project-folder/src/brave
npm install
# the Chromium source is downloaded, which has a large history (gigabytes of data)
# this might take really long to finish depending on internet speed
npm run init
brave-core based android builds should use npm run init -- --target_os=android --target_arch=arm (or whichever CPU type you want to build for)
brave-core based iOS builds should use npm run init -- --target_os=ios
You can also set the target_os and target_arch for init and build using:
npm config set target_os android
npm config set target_arch arm
Additional config needed to build are documented at https://github.com/brave/brave-browser/wiki/Build-configuration
Internal developers can find more information at https://github.com/brave/internal/wiki/Build-configuration
Build Brave
The default build type is component.
# start the component build compile
npm run build
To do a release build:
# start the release compile
npm run build Release
brave-core based android builds should use npm run build -- --target_os=android --target_arch=arm or set the npm config variables as specified above for init
brave-core based iOS builds should use the Xcode project found in ios/brave-ios/App. You can open this project directly or run npm run ios_bootstrap -- --open_xcodeproj to have it opened in Xcode. See the iOS Developer Environment for more information on iOS builds.
Build Configurations
Running a release build with npm run build Release can be very slow and use a lot of RAM, especially on Linux with the Gold LLVM plugin.
To run a statically linked build (takes longer to build, but starts faster):
npm run build -- Static
To run a debug build (Component build with is_debug=true):
npm run build -- Debug
NOTE: the build will take a while to complete. Depending on your processor and memory, it could potentially take a few hours.
Run Brave
To start the build:
npm start [Release|Component|Static|Debug]
Update Brave
npm run sync -- [--force] [--init] [--create] [brave_core_ref]
This will attempt to stash your local changes in brave-core, but it's safer to commit local changes before running this
npm run sync will (depending on the below flags):
- 📥 Update sub-projects (chromium, brave-core) to latest commit of a git ref (e.g. tag or branch)
- 🤕 Apply patches
- 🔄 Update gclient DEPS dependencies
- ⏩ Run hooks (e.g. to perform
npm installon child projects)
| flag | Description |
|---|---|
[no flags] |
updates chromium if needed and re-applies patches. If the chromium version did not change, it will only re-apply patches that have changed. Will update child dependencies only if any project needed updating during this script run. **Use this if you want the script to manage keeping you up to date instead of pulling or switching branches manually. ** |
--force |
updates both Chromium and brave-core to the latest remote commit for the current brave-core branch and the Chromium ref specified in brave-core/package.json (e.g. master or 74.0.0.103). Will re-apply all patches. Will force update all child dependencies. **Use this if you're having trouble and want to force the branches back to a known state. ** |
--init |
force update both Chromium and brave-core to the versions specified in brave-core/package.json and force updates all dependent repos - same as npm run init |
--sync_chromium (true/false) |
Will force or skip the chromium version update when applicable. Useful if you want to avoid a minor update when not ready for the larger build time a chromium update may result in. A warning will be output about the current code state expecting a different chromium version. Your build may fail as a result. |
-D, --delete_unused_deps |
Will delete from the working copy any dependencies that have been removed since the last sync. Mimics gclient sync -D. |
Run npm run sync brave_core_ref to checkout the specified brave-core ref and update all dependent repos including chromium if needed.
Scenarios
Create a new branch:
> cd src/brave
src/brave> git checkout -b branch_name
Checkout an existing branch or tag:
src/brave> git fetch origin
src/brave> git checkout [-b] branch_name
src/brave> npm run sync
...Updating 2 patches...
...Updating child dependencies...
...Running hooks...
Update the current branch to the latest remote:
src/brave> git pull
src/brave> npm run sync
...Updating 2 patches...
...Updating child dependencies...
...Running hooks...
Reset to latest brave-core master (via init, will always result in a longer build and will remove any pending changes in your brave-core working directory):
src/brave> git checkout master
src/brave> git pull
src/brave> npm run sync -- --init
When you know that DEPS didn't change, but .patch files did (quickest attempt to perform a mini-sync before a build):
src/brave> git checkout featureB
src/brave> git pull
src/brave> npm run apply_patches
...Applying 2 patches...
Enabling third-party APIs
- Google Safe Browsing: Get an API key with SafeBrowsing API enabled from https://console.developers.google.com/. Update the
GOOGLE_API_KEYenvironment variable with your key as per https://www.chromium.org/developers/how-tos/api-keys to enable Google SafeBrowsing.
Development
- Security rules from Chromium
- IPC review guidelines (in particular this reference)
- Brave's internal security guidelines (for employees only)
- Rust usage
Troubleshooting
See Troubleshooting for solutions to common problems.