electron/patches/chromium/resource_file_conflict.patch
electron-roller[bot] b711860d21
chore: bump chromium to 102.0.4971.0 (main) (#33454)
* chore: bump chromium in DEPS to 102.0.4965.0

* chore: 3-way merge of chromium/printing.patch

* chore: update patch shear in chromium/picture-in-picture.patch

* chore: update patches

* 3101519: Window Placement: Prototype fullscreen companion window support

Xref: https://chromium-review.googlesource.com/c/chromium/src/+/3101519

build: add popup_preventer.cc, .h to our library. It's needed because
FullscreenController, we were already using, started aggregating a
PopupPreventer in 3101519.

* chore: bump chromium in DEPS to 102.0.4967.0

* Revert "3101519: Window Placement: Prototype fullscreen companion window support"

This reverts commit fc215cb99c464e939882ed3f5cf8e9874a8e3311.

Adding popup_preventer might not be the right solution; there are
cascading dependencies.

* 3551449: Add service-based usage for system print settings

Xref: https://chromium-review.googlesource.com/c/chromium/src/+/3551449

chore: fix code shear in patches/chromium/printing.patch

* chore: update patches

* chore: bump chromium in DEPS to 102.0.4969.0

* chore: update patches

* chore: bump chromium in DEPS to 102.0.4971.0

* chore: update fix_patch_out_permissions_checks_in_exclusive_access.patch

Refs https://chromium-review.googlesource.com/c/chromium/src/+/3101519

PopupunderPreventer is not useful in //electron since the window
attributes are controlled by the user via setWindowOpenHandler.

* chore: update patches

* Add FirstPartySetsHandler as a interface class in content API.

https://chromium-review.googlesource.com/c/chromium/src/+/3503410

* Create a new MediaStreamRequestType for GetOpenDevice

https://chromium-review.googlesource.com/c/chromium/src/+/3541939

* Support site isolation for <webview> tags in WebViewRendererState.

https://chromium-review.googlesource.com/c/chromium/src/+/3537735

* ci: update xcode version

Refs https://chromium-review.googlesource.com/c/chromium/src/+/3544199
https://developer.apple.com/documentation/screencapturekit/capturing_screen_content_in_macos

Co-authored-by: electron-roller[bot] <84116207+electron-roller[bot]@users.noreply.github.com>
Co-authored-by: Charles Kerr <charles@charleskerr.com>
Co-authored-by: PatchUp <73610968+patchup[bot]@users.noreply.github.com>
Co-authored-by: deepak1556 <hop2deep@gmail.com>
2022-03-30 14:08:58 -04:00

79 lines
2.9 KiB
Diff

From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: Jeremy Apthorp <nornagon@nornagon.net>
Date: Thu, 20 Sep 2018 17:48:59 -0700
Subject: resource_file_conflict.patch
Resolve conflict between //chrome's .pak files and //electron's. The paths
that chrome code hardcodes require that we generate resources at these
paths, but GN throws errors if there are multiple targets that generate the
same files.
This is due to the hardcoded names here:
https://chromium.googlesource.com/chromium/src/+/69.0.3497.106/ui/base/resource/resource_bundle.cc#780
and here:
https://chromium.googlesource.com/chromium/src/+/69.0.3497.106/ui/base/resource/resource_bundle_mac.mm#50
This isn't needed on Mac because resource files are copied into the app bundle,
and are built in `$root_out_dir/electron_repack` (while Chromium's resources
target `$root_out_dir/repack`), but on Windows and Linux, the resource files go
directly in `$root_out_dir`, and so they conflict.
We don't actually ever generate Chromium's resource paks, but without this
patch, GN refuses to generate the ninja files:
ERROR at //tools/grit/repack.gni:35:3: Duplicate output file.
action(_repack_target_name) {
^----------------------------
Two or more targets generate the same output:
chrome_100_percent.pak
This is can often be fixed by changing one of the target names, or by
setting an output_name on one of them.
Collisions:
//chrome:packed_resources_100_percent
//electron:packed_resources_100_percent
See //tools/grit/repack.gni:35:3: Collision.
action(_repack_target_name) {
^----------------------------
Some alternatives to this patch:
1. Refactor upstream in such a way that the "chrome" pak names were
configurable, for instance by adding a method to ResourceBundle::Delegate that
LoadChromeResources would check.
2. Pass a Delegate that overrides `GetPathForResourcePack`, check for the
`chrome_{100,200}_percent.pak` filenames, and rewrite them to
`electron_{100,200}_percent.pak`.
3. Initialize the resource bundle with DO_NOT_LOAD_COMMON_RESOURCES and load
the paks ourselves.
None of these options seems like a substantial maintainability win over this patch to me (@nornagon).
diff --git a/chrome/BUILD.gn b/chrome/BUILD.gn
index f1e0552dedf377238e9cd9d24a5ebea77ed83717..1f86073736f849e797e029678bc212ce96ba0bd9 100644
--- a/chrome/BUILD.gn
+++ b/chrome/BUILD.gn
@@ -1547,7 +1547,7 @@ if (is_chrome_branded && !is_android) {
}
}
-if (!is_android) {
+if (!is_android && !is_electron_build) {
chrome_paks("packed_resources") {
if (is_mac) {
output_dir = "$root_gen_dir/repack"
@@ -1576,6 +1576,12 @@ if (!is_android) {
}
}
+if (is_electron_build) {
+ group("packed_resources") {
+ public_deps = [ "//electron:packed_resources" ]
+ }
+}
+
repack("unit_tests_pak") {
sources = [ "$root_gen_dir/chrome/chrome_test_resources.pak" ]
output = "$root_out_dir/unit_tests.pak"