This test is flaky.
On Windows it occasionally crashes in
safe_browsing::IncidentReportingService::Receiver::AddIncidentForProfile [0x00007FF7331FCD50+336]
(C:\ws\src\chrome\browser\safe_browsing\incident_reporting\incident_reporting_service.cc:227)
safe_browsing::PreferenceValidationDelegate::OnSplitPreferenceValidation [0x00007FF735421392+274]
(C:\ws\src\chrome\browser\safe_browsing\incident_reporting\preference_validation_delegate.cc:125)
prefs::mojom::TrackedPreferenceValidationDelegateStubDispatch::Accept
On MacOS it times out and gets killed.
In both cases the test seems to run to the end and encounters problems
on shutting down.
With cr128 new dir android_clang_arm64_with_system_allocator appeared at out folder.
It caused the `generate_breakpad_symbols.py` script fail. After investigation it turned out
it is safe to remove that check, symbols are generated well. In addition, after
brave-core/pull/20849 we supply only one ABI per package.
Related Chromium change:
https://source.chromium.org/chromium/chromium/src/+/7b17414a82198fe945eb56aa1c50c2608a6a9f63
Reland "Reland "Reland "Reland "Add toolchains without PartitionAlloc-Everywhere for dump_syms et al""""
This is a reland of commit 4aceb04adee20a09c1e31760e8c6dafac2563d31
Which was a reland of commit 5e6def5bd2aa9cdbf69608a8edc32b5de696c091
Which was a reland of commit 818e126f4350095dd0a54566ded107f0a5065f6f
Which was a reland of commit 38c00784bc98a5dc885b06f5a0e738386c5f7df7
When PartitionAlloc is linked into an executable, it takes over the
system allocator (malloc, new, etc), which is called PartitionAlloc-
Everywhere (or PA-E). When this occurs in dump_syms, we see that PA
hits OOM and causes dump_syms to crash while generating the symbols
for chrome. It's not at all clear why PA hits OOM but the system
allocator does not, it occurs during construction of a std::string (on
my machine anyway when I am running it in gdb, maybe elsewhere on bots).
This happens on all platforms that we run dump_syms on as part of the
official build: on linux and on mac, building for at least linux,
android, chromeos, and mac. See also crbug.com/345514993.
So we want to build dump_syms and other breakpad executables in a way
that uses the system allocator. To do that we need to disable the
use_partition_alloc_as_malloc GN variable. As this variable is global,
we need a separate toolchain in order to disable it.
We introduce a new toolchain with the suffix `_with_system_allocator`
that can be used for this purpose. Initially we intended to use the
Rust host build tools toolchain for this purpose, however we require
careful naming to avoid toolchain collisions. For instance if building
on a Linux x64 machine with an Other x64 target, we can have two
toolchains:
- default_toolchain: //build/toolchain/other:clang_x64
- host_toolchain: //build/toolchain/other:clang_x64
While these have different labels, it is the name at the end that is
used as their output directory (this is hardcoded in GN). But they
avoid colliding because the default toolchain is not placed in a
subdirectory and uses the `root_build_dir`. However when we add another
toolchain with them, they both get subdirs and collide:
- for target: //build/toolchain/other:clang_x64_with_system_allocator
- for host: //build/toolchain/linux:clang_x64_with_system_allocator
Now both toolchains try to write to the clang_x64_with_system_allocator
directory which causes errors. To avoid this, we actually make two
toolchains per toolchain, one with a `host_` tag inside it.
- target: //build/toolchain/other:clang_x64_with_system_allocator
- unused: //build/toolchain/linux:clang_x64_with_system_allocator
- unused: //build/toolchain/other:clang_x64_host_with_system_allocator
- host: //build/toolchain/linux:clang_x64_host_with_system_allocator
Then, when building for the host we choose the `host_` variety, which
is specified in the `host_system_allocator_toolchain variable`. And
when building for default target, we choose the non-`host_` one, which
is specified in the `default_system_allocator_toolchain` variable.
More clever strategies that try to avoid creating the unused toolchains
above do not seem possible. Inside the toolchain-creating template,
it is not clear how to determine which toolchain is being created, as
the get_label_info() function on `target_name` does not produce
anything that matches exactly with the string in `default_toolchain` or
`host_toolchain`. We also tried using the current_cpu and current_os,
however the `toolchain_args.current_os` is not actually set correctly in
the default toolchain when targeting ChromeOS. The current_os variable
is "chromeos" but inside the toolchain_args, it is "linux". So we just
make extra toolchains (which can't be used or they'd make build errors)
and we don't refer to them from the `host_system_allocator_toolchain`
and `default_system_allocator_toolchain` variables, which makes them
effectively inaccessible.
In the process we learnt many things about how the breakpad executables
are built. When you build them for the default toolchain, such as by
building `//third_party/breakpad:dump_syms`, it redirects to the *host*
toolchain on many platforms, but not on all platforms. This ends up
putting a binary that may not work on the target machine in the
`root_build_dir` which is highly unusual, but it is required by our
testing scripts/infra.
The key insight added here is that the toolchain that it should be
built with is the platform from where the tests on the target will be
*launched*. On Android, iOS, and ChromeOS, the tests are launched from
the host machine and that's where the breakpad executables are run. We
encode this explicitly in the breakpad GN file.
One additional exception is that the breakpad tools do not build on
Windows ARM, so when building on Windows x64 for Windows ARM, while
the tests are launched from the ARM machine, we target the host x64
machine still. This relies on the ARM machine being able to run the
x64 binaries through emulation.
There's no change here in how the breakpad binaries are built, but it
is now more explicitly encoded and documented. What did change is that
since we use a separate toolchain for building these tools, we also
turn off component build in them. This allows us to replace the use
of symlinks with copying (or hardlinking) the binaries from the
toolchain's root directory up to the root_build_dir. This enables
support for building these tools in the default_toolchain on Windows,
something which was not possible before.
Additional fixes from the original CL:
MSAN is disabled in the toolchain with the system allocator as we only
support MSAN in the default toolchain. If another toolchain has MSAN
enabled it will try to also generate the MSAN instrumented libraries
in the default toolchain's directory and they collide. This is similar
to the rust host build tools toolchain, but there we disable all
sanitizers. For the system allocator toolchain, we disable MSAN but
retain the ability to build these tools with ASAN or UBSAN if needed.
Angle's GN generation is fixed by not setting the PA variable directly
from the toolchain. We add a variable in toolchain.gni that is always
present, and set that. Then in the PA gni files, we check for that
variable before enabling PA-Everywhere (and BRP, etc).
Devtools standalone overrides BUILDCONFIG.gn but was not re-defining
the TESTONLY_AND_VISIBILITY variable, so this is done in
https://chrome-internal-review.googlesource.com/c/devtools/devtools-internal/+/7412037
iOS official internal builders are now using the path to the
root_build_dir for its dump_syms exe path from
https://chrome-internal-review.googlesource.com/c/chrome/ios_internal/+/7411376
and it expects the executable to be for the host. A TODO is added
in the breakpad BUILD.gn file regarding cross-compiling for a
different mac machine architecture that will upload/launch tests to
the iOS device.
Mac and Windows internal official builders are fixed by having the
symupload tool depended on and built for the default toolchain so that
it's present in the root_build_dir, but making this binary always
redirect through the host_system_allocator_toolchain. The symupload
binary is only run on official builders, it's not part of test
failure reporting like dump_syms.
Clank orderfile generator had a GN error due to PA-E being off but
BRP being enabled. This is resolved by the fix for Angle, by turning
off all PA-E and BRP related stuff when the toolchain turns off PA-E.
See https://crbug.com/347976629.
Further additional fixes from the original CL:
The minidump_fuzzer is added to the default toolchain, redirecting to
the test-launcher toolchain.
The windows host system-allocator toolchain is forced to use the host
cpu, rather than using the the x86 cpu when cross-compiling.
The Linux-to-Windows cross build avoids putting a `.exe` suffix on
executables built for the host system-allocator toolchain as targets
for Linux do not have them, and then GN can't find the requested
target.
Even more additional fixes:
The previous attempt to get the host system-allocator toolchain to use
the host cpu on Windows was incomplete. It only updated the non-clang
toolchain, and it missed changing the environment to point to the host
cpu's sdk. This is now done correctly.
Removed the redundant output_name field in the windows symupload
executable target, as the executable target is now named symupload, and
not symupload_win.
Explicitly add a `$host_toolchain/symupload` alias on Mac ARM so that
the recipes which explicitly build and run that path will work when
this lands. Once it reaches stable we can remove those explicit paths
from the recipes.
And additional fixes after that:
The high-end fuzzer bot does not build minidump_fuzzer so avoid
generating the copy_exe rule for it there.
Bug: 345514993, b/342251590, 347976629, 349268750
Change-Id: Ib6fd0b8cbde33fd69c609c0232de24a337648b73
Cq-Include-Trybots: luci.chromium.try:linux-centipede-asan-rel
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5675706
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/cad450358f5e8ec89016a104a44d2cb951b2f8a4
commit cad450358f5e8ec89016a104a44d2cb951b2f8a4
Author: S. Ganesh <ganesh@chromium.org>
Date: Thu Jul 18 17:43:11 2024 +0000
Chrome rename: limit the rename operation to 15 seconds
Chrome rename has been identified as very slow on some startups. To
provide users with a quicker launch experience, this CL limits the
rename operation to approximately 15 seconds.
The next CL will gradually backoff on the wait at each attempt to
rename, instead of a fixed 15 seconds.
Bug: b/348199036,b/40792898
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/60d643d8c9003e8a6bd3158f20bf197ad8d505f4
commit 60d643d8c9003e8a6bd3158f20bf197ad8d505f4
Author: Zack Han <zackhan@chromium.org>
Date: Wed Jun 26 18:09:59 2024 +0000
[SBER Deprecation] Hide SBER opt-in toggle button when it is deprecated.
In this CL, we check the value of the extended reporting deprecation
flag and determine whether to show the extended reporting opt-in UI or
not on the security settings page.
Bug: 336547987
We were disabling these too aggressively. Re-enabling the ones that
don't fail with special interest in CaptivePortal tests due verify our
patch in ShouldExcludeNavigationFromUpgrades function
in HttpsUpgradesInterceptor doesn't interfere with the upstream's
captive portal code.
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/6a80cd70fe4032a33af8a2367630469991bceb9f
commit 6a80cd70fe4032a33af8a2367630469991bceb9f
Author: Mustafa Emre Acer <meacer@chromium.org>
Date: Thu Jun 27 19:57:29 2024 +0000
[HTTPS Upgrades] Disable for captive portal login URLs
When Chrome detects that it's behind a captive portal, it automatically
opens a new tab or popup pointing to the captive portal's login URL.
Presently, HTTPS Upgrades treats this a normal tab and attempts to
upgrade it.
Most captive portals don't allow HTTPS requests to go through
before the user logs in, so HTTPS Upgrades will fall back to the http
URL as usual. However, some portals allow HTTPS. This may cause
an empty page to be displayed to the user if the request is upgraded,
e.g. to https://www.gstatic.com/generate_204.
This CL disables upgrades on the first navigation to the captive
portal login URL when a portal is detected, and the HTTPS-First Mode
interstitial is not enabled.
Bug: 343947168
https://source.chromium.org/chromium/chromium/src/+/344b25db37e9c8d52316db5830a4a5dc1571f4c3
commit 344b25db37e9c8d52316db5830a4a5dc1571f4c3
Author: Sylvain Defresne <sdefresne@chromium.org>
Date: Tue Jul 16 17:40:28 2024 +0000
Reland "Preparation for decoupling creation/initialization of context"
This is a reland of https://crrev.com/c/5678966. The
original version of the CL forgot to initialize an
member variable of MappingInfo{} causing undefined
behavior (found via failures of some tests).
This version of the CL fixes the MappingInfo{} struct
to correctly initialize all member variables.
In the latest upstream toolchain update the previous version of this
crate stopped building. This change adds the updated version of the
crate and its dependencies.
Chromium change:
https://chromium.googlesource.com/chromium/src/+/bcb991f
commit bcb991f3bbeffa499fedd785f30c1fe18bd90e89
Author: Mikel Astiz <mastiz@chromium.org>
Date: Thu Jul 18 12:00:00 2024 +0000
[sync] Move CommonControllerBuilder to dedicated file
No behavioral changes, pure refactoring.
Introduced recently in https://crrev.com/c/5658192, it was temporarily
left in sync_api_component_factory_impl.cc to minimize code changes. As
a quick follow-up, this patch moves the code to a dedicated file, along
with minor improvements such as better documentation and addressing a
TODO about unnecessary member fields in SyncApiComponentFactoryImpl.
Bug: 335688372
Chromium change:
https://chromium.googlesource.com/chromium/src/+/c0b3862a5344c50383c2e1abcd0eb061882b0ff0
commit c0b3862a5344c50383c2e1abcd0eb061882b0ff0
Author: Jan Keitel <jkeitel@google.com>
Date: Fri Jul 19 15:05:46 2024 +0000
Rename GoogleGroupsUpdaterService to GoogleGroupsManager.
This CL takes care of a TODO left from an earlier change. It reflects
that the service is now responsible for more than updating Google
Groups prefs.
Fixed: 348575889
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/125660b7b09b42db0528b2a3d5bcac12516c21eb
commit 125660b7b09b42db0528b2a3d5bcac12516c21eb
Author: Andy Paicu <andypaicu@chromium.org>
Date: Thu Jul 18 13:10:20 2024 +0000
[PEPC] Add HaTS survery filters for PEPC prompts
This CL adds 2 new filters to permission HaTS:
1) pepc_prompt_position_filter: window_middle|near_element|legacy_prompt
2) initial_permission_status_filter: allow | ask | block
These fields allows us to target surveys for users that have seen a
particular PEPC prompt version (e.g. the "previously granted") prompt.
Additionally these 2 fields are reported as PSD.
Fixed: 345406251
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/5dba66a54a025ca76cdf79ae0f117c15601a6763
commit 5dba66a54a025ca76cdf79ae0f117c15601a6763
Author: Keren Zhu <kerenzhu@chromium.org>
Date: Fri Jul 19 01:28:07 2024 +0000
preload-topchrome: add TopChromeWebUIConfig::ShouldAutoResizeHost()
`webui_resizes_host` controls if the WebUI content host view should
automatically resize to fit its content. It was only available in the
WebUIContentsWrapperT parameter list. This makes it difficult for the
preload manager to configure the WebContents ahead of creating the
wrapper.
This patch moves the parameter to
TopChromeWebUIConfig::ShouldAutoResizeHost() so that the preload manager
can read it for preloading.
This patch has no behavior change. The integration with the preload
manager will come in a follow up CL.
Bug: 339049707, 40168622
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/5dba66a54a025ca76cdf79ae0f117c15601a6763
commit 5dba66a54a025ca76cdf79ae0f117c15601a6763
Author: Keren Zhu <kerenzhu@chromium.org>
Date: Fri Jul 19 01:28:07 2024 +0000
preload-topchrome: add TopChromeWebUIConfig::ShouldAutoResizeHost()
`webui_resizes_host` controls if the WebUI content host view should
automatically resize to fit its content. It was only available in the
WebUIContentsWrapperT parameter list. This makes it difficult for the
preload manager to configure the WebContents ahead of creating the
wrapper.
This patch moves the parameter to
TopChromeWebUIConfig::ShouldAutoResizeHost() so that the preload manager
can read it for preloading.
This patch has no behavior change. The integration with the preload
manager will come in a follow up CL.
Bug: 339049707, 40168622
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/5dba66a54a025ca76cdf79ae0f117c15601a6763
commit 5dba66a54a025ca76cdf79ae0f117c15601a6763
Author: Keren Zhu <kerenzhu@chromium.org>
Date: Fri Jul 19 01:28:07 2024 +0000
preload-topchrome: add TopChromeWebUIConfig::ShouldAutoResizeHost()
`webui_resizes_host` controls if the WebUI content host view should
automatically resize to fit its content. It was only available in the
WebUIContentsWrapperT parameter list. This makes it difficult for the
preload manager to configure the WebContents ahead of creating the
wrapper.
This patch moves the parameter to
TopChromeWebUIConfig::ShouldAutoResizeHost() so that the preload manager
can read it for preloading.
This patch has no behavior change. The integration with the preload
manager will come in a follow up CL.
Bug: 339049707, 40168622
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/5dba66a54a025ca76cdf79ae0f117c15601a6763
commit 5dba66a54a025ca76cdf79ae0f117c15601a6763
Author: Keren Zhu <kerenzhu@chromium.org>
Date: Fri Jul 19 01:28:07 2024 +0000
preload-topchrome: add TopChromeWebUIConfig::ShouldAutoResizeHost()
`webui_resizes_host` controls if the WebUI content host view should
automatically resize to fit its content. It was only available in the
WebUIContentsWrapperT parameter list. This makes it difficult for the
preload manager to configure the WebContents ahead of creating the
wrapper.
This patch moves the parameter to
TopChromeWebUIConfig::ShouldAutoResizeHost() so that the preload manager
can read it for preloading.
This patch has no behavior change. The integration with the preload
manager will come in a follow up CL.
Bug: 339049707, 40168622
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/5dba66a54a025ca76cdf79ae0f117c15601a6763
commit 5dba66a54a025ca76cdf79ae0f117c15601a6763
Author: Keren Zhu <kerenzhu@chromium.org>
Date: Fri Jul 19 01:28:07 2024 +0000
preload-topchrome: add TopChromeWebUIConfig::ShouldAutoResizeHost()
`webui_resizes_host` controls if the WebUI content host view should
automatically resize to fit its content. It was only available in the
WebUIContentsWrapperT parameter list. This makes it difficult for the
preload manager to configure the WebContents ahead of creating the
wrapper.
This patch moves the parameter to
TopChromeWebUIConfig::ShouldAutoResizeHost() so that the preload manager
can read it for preloading.
This patch has no behavior change. The integration with the preload
manager will come in a follow up CL.
Bug: 339049707, 40168622
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/5dba66a54a025ca76cdf79ae0f117c15601a6763
commit 5dba66a54a025ca76cdf79ae0f117c15601a6763
Author: Keren Zhu <kerenzhu@chromium.org>
Date: Fri Jul 19 01:28:07 2024 +0000
preload-topchrome: add TopChromeWebUIConfig::ShouldAutoResizeHost()
`webui_resizes_host` controls if the WebUI content host view should
automatically resize to fit its content. It was only available in the
WebUIContentsWrapperT parameter list. This makes it difficult for the
preload manager to configure the WebContents ahead of creating the
wrapper.
This patch moves the parameter to
TopChromeWebUIConfig::ShouldAutoResizeHost() so that the preload manager
can read it for preloading.
This patch has no behavior change. The integration with the preload
manager will come in a follow up CL.
Bug: 339049707, 40168622
Chromium change:
https://source.chromium.org/chromium/chromium/src/+/5dba66a54a025ca76cdf79ae0f117c15601a6763
commit 5dba66a54a025ca76cdf79ae0f117c15601a6763
Author: Keren Zhu <kerenzhu@chromium.org>
Date: Fri Jul 19 01:28:07 2024 +0000
preload-topchrome: add TopChromeWebUIConfig::ShouldAutoResizeHost()
`webui_resizes_host` controls if the WebUI content host view should
automatically resize to fit its content. It was only available in the
WebUIContentsWrapperT parameter list. This makes it difficult for the
preload manager to configure the WebContents ahead of creating the
wrapper.
This patch moves the parameter to
TopChromeWebUIConfig::ShouldAutoResizeHost() so that the preload manager
can read it for preloading.
This patch has no behavior change. The integration with the preload
manager will come in a follow up CL.
Bug: 339049707, 40168622
This function is shadowed in our implementation, however the arglist
must match for linking.
Chromium change:
https://chromium.googlesource.com/chromium/src/+/63cb48e3a4e7d68bb4b6d0db88885500e49902c5
commit 63cb48e3a4e7d68bb4b6d0db88885500e49902c5
Author: Christian Xu <christianxu@google.com>
Date: Thu Jul 18 13:18:07 2024 +0000
[iOS][Tabs] Add flag to AttachTabHelpers for BottomSheet presentation
This CL adds a flag to filter tab helpers in AttachTabHelpers for a
bottom sheet presentation.
Bug: 349549576
It seems reference to toolbar_hairline_height was removed at TabListRecyclerView.setShadowVisibility, but it is still at ToolbarTest.testToggleTabStripVisibility.
Related Chromium change:
https://source.chromium.org/chromium/chromium/src/+/399edb13017213bcf2ac0561b47879c13c43b11d
[Tab Switcher] Fix missing hairlines
Fix missing hairlines on the tab switcher and tab grid dialog.
For the Tab Switcher this is implemented in a generic manner via the
Hub. The Hub adds a hairline above the pane host view just below the
toolbar. The pane controls the visibility of the hairline via a boolean
observable supplier.
For the tab switcher the boolean observable supplier is driven by a
RecyclerView ScrollListener. This same mechanism is also reused to add
a bespoke hairline to the tab grid dialog.
Low-Coverage-Reason: OTHER HubColors change uncovered lines are not reachable.
Fixed: 353964686
Change-Id: I917262db87e71f9d12dbc02b941a1891aa0439c8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5723030
Related Chromium change:
https://source.chromium.org/chromium/chromium/src/+/a15398a86222b65b458c65531ebaa6c8095b64df
[Start] Remove HostSurface.
In this CL, we remove:
1) HostSurface of BrowserUiUtils;
2) Deprecate SurfaceType.START_SURFACE of FeedLaunchReliabilityLogger;
3) Remove start surface related metrics from magic stack metrics.
OBSOLETE_HISTOGRAMS=Patterned histogram MagicStack.Clank.{ModuleDelegateHost}.* are replaced by MagicStack.Clank.NewTabPage.* since start surface will go away.
Bug: 344651414
Change-Id: I552316701b1f41c6337113f03bede9e6db247c0a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5721317
The values for this user input types are now part of an enum class. This
change has no other functional effect.
Chromium change:
https://chromium.googlesource.com/chromium/src/+/ae99ae281ffc2fe19024f86c5c64939efc1b2e87
commit ae99ae281ffc2fe19024f86c5c64939efc1b2e87
Author: Avi Drissman <avi@chromium.org>
Date: Mon Jul 22 20:44:28 2024 +0000
Update EventType names
EventType will become an enum class, so all uses of its enum values
need a scope. Because we have to modify all usage anyway, modernize
the naming while doing that.
This is a mechanical change.
There will be a follow-up change to actually switch EventType to be
an enum class rather than an enum.
Bug: 285921876
There is an override for a `SelectFile` call in `DownloadFilePicker`,
which manipulates the title argument. Recently, this `SelectFile` method
has dropped the `param` arg, and the override should reflect that.
Chromium change:
https://chromium.googlesource.com/chromium/src/+/7b865af5edfce7ef3b1cf82794845c6eb0c4f6f9
commit 7b865af5edfce7ef3b1cf82794845c6eb0c4f6f9
Author: Elly <ellyjones@chromium.org>
Date: Mon Jul 22 23:05:54 2024 +0000
ui: remove SelectFile params argument
This change removes the params argument to
ui::SelectFileDialog::SelectFile() and removes the value of it passed at
every call site (which is nullptr everywhere).
Bug: 340178601
This feature flag looks gutted on upstream already, and the relevant
code is part of attributing reporting.
Chromium change:
https://chromium.googlesource.com/chromium/src/+/cbef7cdebb7f2ccf8eef553b31797cbea57c60b2
commit cbef7cdebb7f2ccf8eef553b31797cbea57c60b2
Author: Nan Lin <linnan@chromium.org>
Date: Mon Jul 22 23:18:54 2024 +0000
Remove AttributionReportingCrossAppWeb OT code
This OS has been ended for over three months and the feature is
shipped. This cleans up all of the OT related code and tests.
Bug: 331926920
This function is not reliable to be used in production, and therefore
has been marked as a debug only function on upstream, while all the
production cases are being migrated. The same should also be done in
brave.
Chromium change:
https://chromium.googlesource.com/chromium/src/+/c80a77db069542f63deeb1612ddd607da03795bd
commit c80a77db069542f63deeb1612ddd607da03795bd
Author: manukh <manukh@chromium.org>
Date: Fri Jul 19 21:53:25 2024 +0000
[omnibox][iph] `GetAdditionalInfo()`-> `GetAdditionalInfoForDebugging()`
Using `GetAdditionalInfo()` for non-debugging is a bit ugly, like:
```
class X {
// methods...
map<string, string> fields;
}
```
instead of
```
class X {
// methods...
int field_1;
bool field_2;
...
}
```
Besides, storing all fields as strings is probably not memory efficient;
then casting them to types is probably not performance efficient or type
safe.
And I'm not sure `additional_info` is handled correctly when merging
duplicate matches, copying matches, or moving matches.
This CL renames the method and adds todo comments where it's called for
non-debugging purposes. Most of the callsites are old and probably not
worth the effort to clean up immediatly. But we recently added a new
callsite for gemini/featured search IPH; hopefully the rename will help
avoid introducing new callsites.
Upstream has hidden a couple of files behind `enable_feed_v2` to reduce
binary size. However this functions are required for brave news
`feed::FetchRssLinks`.
Chromium change:
https://chromium.googlesource.com/chromium/src/+/d3500b942cde04737bc13021173b6ffa11aaf1b9
commit d3500b942cde04737bc13021173b6ffa11aaf1b9
Author: Chris Davis <chrdavis@microsoft.com>
Date: Mon Apr 29 19:44:45 2024 +0000
Ensure feeds code is excluded if it is not enabled
The feeds (rss) code was getting included even when enable_feed_v2 was
not enabled. This also removes dead code left behind from previous
recent feed-related code removal. This saves ~700k of disk space for
chrome.dll when feeds are disabled.
Bug: 335003908
`ChromeMainDelegate` has changed a few things around the contructor, and
this requires changes to our derived version of it.
Chromium change:
https://chromium.googlesource.com/chromium/src/+/67ea5d76d58578b931aaf4aea06a4d941ef27e38
commit 67ea5d76d58578b931aaf4aea06a4d941ef27e38
Author: Sean Maher <spvw@chromium.org>
Date: Fri Jul 19 20:52:01 2024 +0000
startup: record histogram and trace event for base::PreReadFile
Since PreReadFile happens before ChromeMain, the time at start/end is
saved, and then passed to ChromeMain. This is only being recorded on
Windows, because it is specific to its DLL loading machinery.
Bug: 325307453
This reverts commit 526fe29c4d.
This is being removed as an upstream fix has landed.
Chromium change:
https://chromium.googlesource.com/chromium/src/+/7baf270e1fc5de3a164057266d8c74ca1ea5c320
commit 7baf270e1fc5de3a164057266d8c74ca1ea5c320
Author: Dylan Cutler <dylancutler@google.com>
Date: Thu Jul 18 22:20:23 2024 +0000
Patch crash when expiring a single partitioned cookie
The crash would occur when we query partitioned cookies across all
partitions (which is supported in extensions, for example), and one
partition only contained a single partition cookie.
This would cause partitioned_cookies_ to be modified while we the code
was using a for-range loop to iterate through it, which causes a
crash.
Bug: 353034832
This reverts commit 0097c66e77.
An upstream fix has been submitted to do away with the need for this
patch/override.
Chromium change:
https://chromium.googlesource.com/chromium/src/+/417d545c4cd6e85f31a830195e4ea8d82ebe2bf9
commit 417d545c4cd6e85f31a830195e4ea8d82ebe2bf9
Author: sangwoo <sko@brave.com>
Date: Thu Jul 18 01:52:20 2024 +0000
Pass title argument to file select dialog on Windows
Currently eventhough we pass title from FileSelectHelper or
DownloadPicker, it's ignored on Windows without obvious reasons.
We should respect the argument from implementation side.
Change-Id: Ie3569d903c6232f891028b4be120d56edf9d6048
This type is now to be used as a replacement to instantiating
`TemplateURLService` on unit tests.
Chromium change:
https://chromium.googlesource.com/chromium/src/+/2862d7f6b0842b53209c8038ec54eba132b55d8b
commit 2862d7f6b0842b53209c8038ec54eba132b55d8b
Author: Jack Yammine <jyammine@google.com>
Date: Thu Jul 18 11:20:17 2024 +0000
Remove deprecated TemplateURLService constructor used in tests
This is part of a multi-CL change [2/4].
We remove the TemplateURLService constructor that was only used for
tests and update the tests accordingly.
Bug: 40287734
This change was done by upstream to allow `local_state` to be passed as
`nullptr` on unit tests.
Chromium change:
https://chromium.googlesource.com/chromium/src/+/82846b50dea07cbdc7f73494d8a39a82603dbaea
commit 82846b50dea07cbdc7f73494d8a39a82603dbaea
Author: Jack Yammine <jyammine@google.com>
Date: Thu Jul 18 08:46:48 2024 +0000
Change local_state to a pointer in SearchEngineChoiceService
This will make it easier to set up unit tests where
g_browser_process->local_state() is null by default.
We previously stopped creating `SearchEngineChoiceService` and
`SearchEngineChoiceDialogService` automatically in tests. We undo
that change.
This is part of a multi-CL change [1/4].
This is a pre-requisite for the TemplateURLService test cleanup
that's in progress in the same bug.
Bug: 40287734
mkarolin
