This document outlines the planned architecture and design principles
behind the tree tab feature. It covers the responsibilities of
various components, data structures, and interaction patterns to ensure
a cohesive and decoupled implementation.
* Add Brave Midnight (Darker) theme feature
This commit introduces the Brave Midnight theme, a darker variant of the
existing dark theme, providing users with enhanced customization options
for their browsing experience.
Key changes:
* Add feature flag `kBraveMidnightTheme` to control theme availability
* Create new preference `kBraveDarkerMode` to store user's theme choice
* Implement UI toggle in Customize Chrome side panel for theme switching
* Add Mojo interface methods for theme state management
Technical implementation:
- Created `browser/ui/color/features.{cc,h}` for feature flag definition
- Added feature flag to `about_flags.cc` for experimental access
- Registered preference in `brave_profile_prefs.cc` when feature is enabled
- Extended Customize Chrome UI with `DarkerThemeToggle` component
- Added Mojo interface methods `GetUseDarkerTheme`/`SetUseDarkerTheme`
The feature is disabled by default and can be enabled via the
`brave-midnight-theme` flag in brave://flags. When enabled, users can
toggle the darker theme through the Customize Chrome side panel.
This change adds a dry run mode to plaster, that can be called with:
```sh
tools/cr/plaster.py check
```
This command can also be called with a list of files, that can be either
`rewrite/` files or `patches/` files.
We are also adding support to plaster for .patchinfo files, allowing a
more efficient way to make sure any given plaster file has should be
regenerated.
### What does plaster do to .patchinfo files
Plaster now generates the contents of a .patchinfo file, and based on
that content it determines if one of these files must be updated:
source, patch, or patchinfo (a combination of npm run update_patches
and npm run apply_patches). A new key is being added to the patchinfo
format, namely, plaster, which is used to store the path and checksum
for the plaster file for a given patch/source set. Files are only
updated on disk if the resulting new content doesn't match the hash of
the file saved in disk.
For now plaster always produce a .patchfile when processing a plaster,
to avoid unnecessary writes and to confirm that submitted patches do
have the expected content. This may change in the future with a more
mature approach where the contents of the patchinfo file may be used
to avoid running all the plaster transformations. This means that for
now we have to pay for a full plaster generation to determine if a file
source/patch/patchinfo are out-of-date.
Resolves https://github.com/brave/brave-browser/issues/47066
This change corrects all crate patches, changing them to point to
`brave/`. This eliminates the need of patching `gnrt vendor` to address
this patch mismatch.
Patches should be created now with:
```sh
git format-patch \
--start-number=101 \
--src-prefix=a/brave/ \
--dst-prefix=b/brave/ \
--output-directory \
third_party/rust/chromium_crates_io/patches/some-crate/ \
HEAD^
```
Resolves https://github.com/brave/brave-browser/issues/46201
This is the initial prototype for 🩹 Plaster. This work is based on a
recenlty worked out proposal:
https://docs.google.com/document/d/1aPf7cMB5Pc_ssKFC_I4-mLHr-7D4lTqsvItSXY-WzQM/
Run this tool with:
```
tools/cr/plaster.py
```
The tool at the moment is in a very early prototyping stage, and there
are many tickets opened for it, to get it into a mature state. The
intent is to manage to deliver this in gradual steps, while acquiring
experience alongside the way.
- Plaster files.
These are TOML files, even though they look pretty similar to ini files.
Each `[[substitution]]` entry represents an individual regex operation to be
applied to a file. The format for plasters is something like this
```toml
[[substitution]]
description = ''
re_pattern = ''
replace = ''
re_flags = ''
count = 0
```
A user can list as many of these entries as necessary for each regex
that one desires to apply to a given source.
Resolves https://github.com/brave/brave-browser/issues/45051
This is the initial documentation around upgrading the upstream tag.
This will serve as an introduction to the concepts around version
upgrading. A follow up PR will go into details on using Brockit for
version upgrading.
Resolve https://github.com/brave/brave-browser/issues/44729
* Persist farbling token per schemeful site.
* Add tests for persistent farbling token.
* Handle shields metadata cleanup on site data remove.
* Update existing tests to work with the new farbling random.
* Disable farbling in some sensitive Chromium tests.
* Simplify GetShieldsMetadata.
* Use ASSERT instead of CHECK in tests.
* Alias objects memory in dumps to see the actual types.
* Few improvements to harden the object alias helper.
* Remove StackObjectCopy from this PR (better to land it separately).
These patches had their target path updated. These files used to be
under `third_party/`.
Chromium change:
https://chromium.googlesource.com/devtools/devtools-frontend/+/e20bdacd076c94ada0411697d8c2c36c8af86dc6
commit e20bdacd076c94ada0411697d8c2c36c8af86dc6
Author: Simon Zünd <szuend@chromium.org>
Date: Tue Aug 27 09:35:53 2024 +0200
[deps] Move ts_library out of third_party
ts_library.py and typescript.gni do not contain any third party code.
They had the Chromium license headers from the beginning. The only
"third-party"ness they have, is that they use the "typescript"
npm package.
R=alexrudenko@chromium.org
Fixed: 362397305
Aleksei Khoroshilov