1. Chromium can fire unrelated permission checks (e.g. 'background-sync')
on the default session. Copy a safeguard `permission === 'fileSystem'` from
"calls twice when trying to query a read/write file handle permissions".
2. add afterEach cleanup: reset setPermissionCheckHandler(null) and
remove ipcMain listeners for 'did-create-file-handle' and
'did-create-directory-handle'.
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Charles Kerr <charles@charleskerr.com>
fix: return numeric `blksize` and `blocks` from asar `fs.stat`
Previously, `fs.stat` on files inside `.asar` archives returned
`undefined` for `blksize` and `blocks`, violating the Node.js API
contract where these fields must be `number | bigint`.
Use `4096` for `blksize` (matching the convention used by `memfs` and
the proposed `node:vfs` module in nodejs/node#61478) and compute
`blocks` as `ceil(size / 512)` (standard 512-byte block units).
Fixes#42686
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: clavin <clavin@electronjs.org>
#47171 migrated `std::deque` to `base::circular_deque` in
`shell/common/crash_keys.cc`. However, `CrashKeyString` wraps a
`crashpad::Annotation` that holds self-referential pointers and
registers itself in a process-global linked list. `circular_deque`
relocates elements on growth (via `VectorBuffer::MoveConstructRange`),
leaving those pointers dangling — causing missing crash keys or a hung
crashpad handler (especially on macOS). The `base/containers/README.md`
warns: "Since `base::deque` does not have stable iterators and it will
move the objects it contains, it may not be appropriate for all uses."
Reverts to `std::deque`, whose block-based layout never relocates
existing elements. Adds a regression test that registers 50 dynamic
crash keys and verifies they all survive a renderer crash.
Notes: Fixed crash keys being lost and the crash reporter hanging on
macOS when many dynamic crash keys were registered.
Made-with: Cursor
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Alexey Kozy <alexey@anysphere.co>
fix: enforce size constraints on window creation on Windows and Linux (#49906)
* enforce size constraints on window creation
* set constraints after resizing on init
* restore conditional centering
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Mitchell Cohen <mitch.cohen@me.com>
fix: re-enable MacWebContentsOcclusion with embedder window fix (#50579)
* fix: re-enable MacWebContentsOcclusion with embedder window fix
Replace the full revert of Chromium's MacWebContentsOcclusion cleanup
with a targeted patch that handles embedder windows shown after
WebContentsViewCocoa attachment. This lets us drop the feature flag
disable in feature_list.cc and re-enable upstream occlusion tracking.
Adds tests for show/hide event counts on macOS and visibility tracking
across multiple child WebContentsViews.
* test: drop show/hide event count assertion
The assertion that 'show' fires exactly once per w.show() call is not
an API guarantee - macOS can send multiple occlusion state
notifications during a single show() when other windows are on screen
(common on CI after hundreds of prior tests). The
visibilitychange-count test in api-web-contents-view-spec.ts covers
the actual invariant we care about.
* fix: ignore WebContentsOcclusionCheckerMac synthetic notifications in window delegate
On macOS 13.3-25.x, Chromium's occlusion checker enables manual
frame-intersection detection and posts synthetic
NSWindowDidChangeOcclusionStateNotification tagged with its class name
in userInfo. These fire when the checker's NSContainsRect heuristic
decides a window is covered by another window's frame, but the real
-[NSWindow occlusionState] hasn't changed.
Our delegate was treating these the same as real macOS notifications
and emitting show/hide events based on occlusionState, which was
unchanged - resulting in spurious duplicate show events when e.g.
Quick Look opened and its frame intersected the BrowserWindow.
V8's second-pass weak callbacks run inside a
DisallowJavascriptExecutionScope: they may touch the V8 API but must
not invoke JS, directly or indirectly. Several Electron Wrappables
(WebContents in particular) emit JS events from their destructors,
so deleting synchronously inside SecondWeakCallback can crash with
"Invoke in DisallowJavascriptExecutionScope" when GC happens to
collect the JS wrapper during a foreground GC task — typically during
shutdown's uv_run drain after a leaked WebContentsView.
This was previously latent and timing-dependent (electron/electron#47420,
electron/electron#45416, podman-desktop/podman-desktop#12409). The
esbuild migration's keepNames option (which wraps every function/class
with an Object.defineProperty call) shifted heap layout enough to make
the spec/fixtures/crash-cases/webcontentsview-create-leak-exit case
reliably reproduce it on every run, giving a clean signal for the fix.
Both WrappableBase and DeprecatedWrappableBase SecondWeakCallback now
post the deletion via base::SequencedTaskRunner::GetCurrentDefault()
so the destructor (and any Emit it does) runs once V8 has left the GC
scope. Falls back to synchronous deletion if no task runner is
available (early/late process lifetime).
Fixeselectron/electron#47420.
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Sam Attard <sattard@anthropic.com>
WebContentsPermissionHelper::CheckPermission was hardcoding
GetPrimaryMainFrame() and deriving the requesting origin from
web_contents_->GetLastCommittedURL(), so the setPermissionCheckHandler
callback always received the top frame's origin and
details.isMainFrame/details.requestingUrl always reflected the main
frame, even when a cross-origin subframe with allow="serial" or
allow="camera; microphone" triggered the check.
Thread the requesting RenderFrameHost through CheckPermission,
CheckSerialAccessPermission, and CheckMediaAccessPermission so the
permission manager receives the real requesting frame. Update the
serial delegate and WebContents::CheckMediaAccessPermission callers to
pass the frame they already have.
Adds a regression test that loads a cross-origin iframe with
allow="camera; microphone", calls enumerateDevices() from within the
iframe, and asserts the permission check handler receives the iframe
origin for requestingOrigin, isMainFrame, and requestingUrl.
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Sam Attard <sattard@anthropic.com>
fix: resolve getFileHandle concurrent stalling by queuing callbacks (#50597)
Previously, concurrent calls to FileSystemAccessPermissionContext::ConfirmSensitiveEntryAccess
for the same file path would silently discard the subsequent callbacks because
the internal callback map used a single callback per file path and std::map::try_emplace
would drop the callback if the key already existed. This caused Promises in JS
(e.g., dirHandle.getFileHandle()) to stall indefinitely.
This commit updates the callback map to hold a vector of callbacks, so all
concurrent requesters for the same filepath are grouped together and resolved
once the asynchronous blocklist check completes.
Notes: Fixed an issue where concurrent `getFileHandle` requests on the same path could stall indefinitely.
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Kunal Dubey <21157775+xakep8@users.noreply.github.com>
The `OnTraceBufferUsageAvailable` callback creates V8 handles via
`Dictionary::CreateEmpty()` before `promise.Resolve()` enters its
`SettleScope` (which provides a `HandleScope`). When the callback
fires asynchronously from a Mojo response (i.e. when a trace session
is active), there is no `HandleScope` on the stack, causing a fatal
V8 error: "Cannot create a handle without a HandleScope".
Add an explicit `v8::HandleScope` at the top of the callback, matching
the pattern used by the other contentTracing APIs which resolve their
promises through `SettleScope` or the static `ResolvePromise` helper.
Made-with: Cursor
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Alexey Kozy <alexey@anysphere.co>
The frameNamesToWindow map was a holdover from the BrowserWindowProxy
IPC shim. Since nativeWindowOpen became the only code path, Blink's
FrameTree::FindOrCreateFrameForNavigation resolves named window targets
directly in the renderer, scoped to the opener's browsing context
group. When a matching named window exists, Blink navigates it without
ever sending a CreateNewWindow IPC to the browser, so this map was
never consulted in the legitimate same-opener case.
The only time the map found a match was when two unrelated renderers
happened to use the same target name, in which case openGuestWindow
would short-circuit before consuming the guest WebContents that
Chromium had already created for the new window, leaking it.
Adds a test verifying Blink handles same-opener named-target reuse
end-to-end without any browser-side tracking.
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Sam Attard <sattard@anthropic.com>
The weak persistent tracking the OffscreenReleaseHolderMonitor was tied
to the texture object, but the release() closure holds a raw pointer to
the monitor via its v8::External data. If JS retained texture.release
while dropping the texture itself, the monitor would be freed on GC and
a later release() call would crash.
Track the release function instead of the texture object. Since the
texture holds release as a property, this keeps the monitor alive as
long as either is reachable.
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Sam Attard <sattard@anthropic.com>
feat: add nativeTheme.shouldDifferentiateWithoutColor on macOS
Adds nativeTheme.shouldDifferentiateWithoutColor on macOS that maps to
NSWorkspace.accessibilityDisplayShouldDifferentiateWithoutColor. If true,
the user has indicated that they prefer UI that differentiates items with
something other than color alone. This is useful for users with color
vision deficiency.
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Robert Böhnke <robb@robb.is>
* fix: correct utility process exit code on Windows
On Windows, process exit codes are 32-bit unsigned integers (DWORD).
When passed from Chromium to Electron as a signed int and then
implicitly converted to uint64_t, values with the high bit set
(e.g., NTSTATUS codes) undergo sign extension, producing incorrect
values.
Cast the exit code to uint32_t before widening to uint64_t to
prevent sign extension and preserve the original Windows exit code.
Fixes#49455
Co-authored-by: João Silva <joaomrsilva@tecnico.ulisboa.pt>
* fix: narrow HandleTermination and Shutdown to uint32_t, add tests
Co-authored-by: João Silva <joaomrsilva@tecnico.ulisboa.pt>
---------
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: João Silva <joaomrsilva@tecnico.ulisboa.pt>
* fix: preserve staged update dir when pruning orphaned update dirs on macOS
The previous squirrel.mac patch cleaned up all staged update directories
before starting a new download. This kept disk usage bounded but broke
quitAndInstall() if called while a subsequent checkForUpdates() was in
flight — the already-staged bundle would be deleted out from under it.
This reworks the patch to read ShipItState.plist and preserve the
directory it references, deleting only truly orphaned update.XXXXXXX
directories. Disk footprint stays bounded (at most 2 dirs: staged +
in-progress) and quitAndInstall() remains safe mid-check.
Also adds test coverage for the quitAndInstall/checkForUpdates race and
a triple-stack scenario where 3 updates arrive without a restart.
Refs https://github.com/electron/electron/issues/50200
Co-authored-by: Samuel Attard <sattard@anthropic.com>
* chore: update patches
---------
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Samuel Attard <sattard@anthropic.com>
Co-authored-by: Keeley Hammond <khammond@slack-corp.com>
* fix: read nodeIntegrationInWorker from per-frame WebPreferences
Previously the renderer checked a process-wide command-line switch to
decide whether to create a Node.js environment for dedicated workers.
When a renderer process hosted multiple WebContents with different
nodeIntegrationInWorker values (e.g. via window.open with overridden
webPreferences in setWindowOpenHandler), all workers in the process
used whichever value the first WebContents set on the command line.
Instead, plumb the flag through blink's WorkerSettings at worker
creation time, copying it from the initiating frame's WebPreferences.
The check on the worker thread then reads the per-worker value. Nested
workers inherit the flag from their parent worker via
WorkerSettings::Copy.
The --node-integration-in-worker command-line switch is removed as it
is no longer consumed.
Co-authored-by: Samuel Attard <sattard@anthropic.com>
* chore: update patches
---------
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Samuel Attard <sattard@anthropic.com>
Co-authored-by: John Kleinschmidt <kleinschmidtorama@gmail.com>
fix: validate protocol scheme names in setAsDefaultProtocolClient
On Windows, `app.setAsDefaultProtocolClient(protocol)` directly
concatenates the protocol string into the registry key path with no
validation. A protocol name containing `\` could write to an arbitrary
subkey under `HKCU\Software\Classes\`, potentially hijacking existing
protocol handlers.
To fix this, add `Browser::IsValidProtocolScheme()` which validates that a protocol
name conforms to the RFC 3986 scheme grammar:
scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
This rejects backslashes, forward slashes, whitespace, and any other
characters not permitted in URI schemes.
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Shelley Vohr <shelley.vohr@gmail.com>
Enter the destination context scope before creating the VideoFrame V8
wrapper, matching the sibling Element and Blob branches. Without this,
ScriptState::ForCurrentRealm resolved to the calling context instead of
the target context, producing an incorrect wrapper.
Also switch to ScriptState::From with an explicit context argument to
make the intent clearer.
Adds spec coverage for VideoFrame crossing the bridge in both
directions and adds VideoFrame to the existing prototype checks.
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Samuel Attard <sattard@anthropic.com>
* test: add failing test for `setFullscreen(false)`
`setFullscreen(false)` should do nothing
when not already in fullscreen, but it hides the menu bar
on Linux.
Co-authored-by: WofWca <wofwca@protonmail.com>
* fix: menu bar hiding on two setFullScreen(false)
This fixes the following bug on Linux (and maybe macOS):
1. Create a window with a menu bar.
2. Call `win.setFullScreen(false)`.
The menu bar will hide.
See the original bug in our project:
https://github.com/deltachat/deltachat-desktop/issues/4752.
Co-authored-by: WofWca <wofwca@protonmail.com>
---------
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: WofWca <wofwca@protonmail.com>
fix: correct window sizing on Linux when constraints on resizability are enforced (#49903)
* fix window sizing on linux when constraints are applied
* added tests
* apply window style directly when changing resizability
* Revert "apply window style directly when changing resizability"
This reverts commit 949e2ee2ab.
* set size constraints for resizability on window and linux
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Mitchell Cohen <mitch.cohen@me.com>
fix: apply zoomFactor from setWindowOpenHandler to window.open() windows
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Shelley Vohr <shelley.vohr@gmail.com>
* chore: bump chromium in DEPS to 146.0.7653.0
* chore: bump chromium in DEPS to 146.0.7653.1
* chore: bump chromium in DEPS to 146.0.7655.0
* chore: bump chromium in DEPS to 146.0.7657.1
* chore: bump chromium in DEPS to 146.0.7659.0
* chore: bump chromium in DEPS to 146.0.7661.0
* chore: bump chromium in DEPS to 146.0.7663.1
* chore: bump chromium in DEPS to 146.0.7665.1
* chore: bump chromium in DEPS to 146.0.7667.1
* chore: bump chromium in DEPS to 146.0.7668.2
* chore: bump chromium in DEPS to 146.0.7670.0
* chore: bump chromium in DEPS to 146.0.7672.1
* chore: bump chromium in DEPS to 146.0.7674.1
* chore: bump chromium in DEPS to 146.0.7676.1
* chore: bump chromium in DEPS to 146.0.7678.1
* chore: bump chromium in DEPS to 146.0.7680.1
* chore: bump chromium in DEPS to 146.0.7680.4
* chore: bump chromium in DEPS to 146.0.7680.0
* chore: bump chromium to 146.0.7666.0 (main) (#49528)
* chore: bump chromium in DEPS to 146.0.7652.0
* fix(patch-conflict): update mas_avoid_private_macos_api_usage context for constrainFrameRect method
The upstream CL added a new constrainFrameRect:toScreen: method override to
NativeWidgetMacNSWindow as part of headless mode window zoom implementation.
The MAS patch's #endif for frameViewClassForStyleMask now correctly appears
after that method, since constrainFrameRect is a public API override that
doesn't need to be guarded.
Ref: https://chromium-review.googlesource.com/c/chromium/src/+/7487666
* fix(patch-conflict): update printing.patch for base::DictValue rename
Updated printing.patch to use the new base::DictValue type name instead of
base::Value::Dict following Chromium's type renaming change. This affects
CompleteUpdatePrintSettings() signature and related code.
Ref: https://chromium-review.googlesource.com/c/chromium/src/+/7509820
* fix(patch-conflict): update accessibility_ui patch for base::DictValue/ListValue rename
Updated adjust_accessibility_ui_for_electron.patch to use the new
base::DictValue and base::ListValue type names instead of base::Value::Dict
and base::Value::List following Chromium's type renaming change.
Ref: https://chromium-review.googlesource.com/c/chromium/src/+/7509820
* chore: update patches
* 6625736: Rename DURABLE_STORAGE to PERSISTENT_STORAGE for consistency | https://chromium-review.googlesource.com/c/chromium/src/+/6625736
* chore: bump chromium in DEPS to 146.0.7653.0
* chore: update patches
* 7000847: add type tag to v8::External for gin_helper function templates
The upstream gin function templates now use v8::ExternalPointerTypeTag
for type safety when using v8::External. Updated Electron's forked
gin_helper function template to use the same kGinInternalCallbackHolderBaseTag
that Chromium's gin uses.
Ref: https://chromium-review.googlesource.com/c/chromium/src/+/7000847
* fix(patch-update): extend V8 Object API deprecation patch for Node.js
Extended the existing patch to cover additional files that use
GetAlignedPointerFromInternalField and SetAlignedPointerInInternalField:
- src/stream_base-inl.h
- src/udp_wrap.cc
- src/js_udp_wrap.cc
- src/node_process_methods.cc
- src/node_snapshotable.cc
- src/base_object.cc
These APIs now require an EmbedderDataTypeTag parameter.
Ref: https://chromium-review.googlesource.com/c/v8/v8/+/7087956
* 7000847: add type tag to v8::External calls in shared_texture
Updated v8::External::New and v8::External::Value calls to use the
kExternalPointerTypeTagDefault tag as required by the V8 API change
that deprecates the tagless versions.
Ref: https://chromium-review.googlesource.com/c/chromium/src/+/7000847
* 7508687: use ChildProcessId for file permission APIs
The ChildProcessSecurityPolicy::CanReadFile and GrantReadFile APIs
now require ChildProcessId instead of int. Updated to use GetID()
instead of GetDeprecatedID() for these specific calls.
Ref: https://chromium-review.googlesource.com/c/chromium/src/+/7508687
* 7000847: add type tag to v8::External calls in callback and osr_converter
The v8::External API now requires an EmbedderPointerTypeTag parameter
for both New() and Value() methods to improve V8 sandbox type safety.
Updated calls in:
- callback.cc: TranslatorHolder constructor and CallTranslator
- osr_converter.cc: OffscreenSharedTextureValue converter
Ref: https://chromium-review.googlesource.com/c/v8/v8/+/7000847
* fixup! 7087956: [api] Promote deprecation of v8::Context and v8::Object API methods
Extended the Node.js patch to cover histogram.cc which also uses
SetAlignedPointerInInternalField and GetAlignedPointerFromInternalField
APIs that now require the EmbedderDataTypeTag parameter.
Ref: https://chromium-review.googlesource.com/c/v8/v8/+/7087956
* chore: bump chromium in DEPS to 146.0.7655.0
* chore: update patches
* 7509043: update WebSpellingMarker type for API change
The upstream Chromium API changed - WebSpellingMarker was moved from a
nested type within WebTextCheckClient to a standalone type in the blink
namespace.
Ref: https://chromium-review.googlesource.com/c/chromium/src/+/7509043
* 7498491: update process_id to use OriginatingProcess type
The upstream Chromium API changed - URLLoaderFactoryParams::process_id
was changed from an integer to a union type network::OriginatingProcess
that distinguishes between browser and renderer processes.
- For browser process requests, use OriginatingProcess::browser()
- For renderer process lookups, check !is_browser() and use
renderer_process().value() to get the child_id
Ref: https://chromium-review.googlesource.com/c/chromium/src/+/7498491
* 5710330: Add crash keys to debug NativeWidgetMacNSWindowBorderlessFrame exception | https://chromium-review.googlesource.com/c/chromium/src/+/5710330
5710330 added a new NSNextStepFrame interface extension and
implementations for NativeWidgetMacNSWindowTitledFrame and
NativeWidgetMacNSWindowBorderlessFrame. These use private macOS APIs
that are not available in Mac App Store builds.
* chore: update patches
* chore: bump chromium in DEPS to 146.0.7661.0
* chore: bump chromium in DEPS to 146.0.7663.0
* fix(patch-conflict): update accessibility_ui for string_view API change
Upstream removed redundant std::string(default_api_type) conversion as part
of a string_view optimization cleanup. Updated patch context to match.
Ref: https://chromium-review.googlesource.com/c/chromium/src/+/7514107
* fix(patch-conflict): update service process launch options for sandbox API refactor
Upstream removed content/common/sandbox_init_win.cc and
content/public/common/sandbox_init_win.h, moving the functionality directly
into ChildProcessLauncherHelper. Updated patch to call
sandbox::policy::SandboxWin::StartSandboxedProcess directly with the
LaunchOptions pointer instead of going through the removed helper.
Ref: https://chromium-review.googlesource.com/c/chromium/src/+/7528253
* fix(patch-conflict): update MAS safestorage for keychain API refactor
Upstream refactored KeychainPassword::GetPassword() to use a new
GetPasswordImpl() helper function with improved error tracking via
base::expected<std::string, OSStatus>. Adapted patch to use the new
GetPasswordImpl with the suffixed account name and handle migration
from legacy accounts through the new API.
Ref: https://chromium-review.googlesource.com/c/chromium/src/+/7516438
* chore: update patches
* chore: bump chromium in DEPS to 146.0.7663.0
* fix: base::Value::Dict -> base::DictValue
https://chromium-review.googlesource.com/c/chromium/src/+/7513889
* fix: include new cookie exclusion reason
https://chromium-review.googlesource.com/c/chromium/src/+/7486527
* fix: enable libc++ ABI flag for trivially copyable std::vector<bool>
Required for changes introduced in the following CL
https://chromium-review.googlesource.com/c/chromium/src/+/7513653
* fixup! fix: base::Value::Dict -> base::DictValue https://chromium-review.googlesource.com/c/chromium/src/+/7513889
* fix: spellcheck not working in tests
https://chromium-review.googlesource.com/c/chromium/src/+/7452579
* fix: cookie test failing due to multiple rejection reasons
https://chromium-review.googlesource.com/c/chromium/src/+/7506629
* fix: macos sizing unmaximized window incorrectly
https://chromium-review.googlesource.com/c/chromium/src/+/7487666
Changes to headless mode caused the unmaximized window to subtract
the height of the menubar.
* fix: skip tests for incompatible BoringSSL ML-DSA crypto
https://boringssl-review.googlesource.com/c/boringssl/+/84929
* test: fix pseudonymization registration in utility process on Linux
Ref: 7486913: Pass pseudonymization salt via shared memory at process launch | https://chromium-review.googlesource.com/c/chromium/src/+/7486913
* fix: restore MAS patch-outs
Restores some `#if !IS_MAS_BUILD()` gates dropped in 773054ad59
* fixup! 7508687: use ChildProcessId for file permission APIs
* fixup! fix(patch-conflict): update MAS safestorage for keychain API refactor
* chore: add note about parallel upstream change
* fixup! Merge remote-tracking branch 'origin/main' into roller/chromium/main
* Revert "fixup! 7508687: use ChildProcessId for file permission APIs"
This reverts commit 05c43e4e5d.
The _impl version has the signature, but not the public interface. :oof:
* fixup! fix(patch-conflict): update MAS safestorage for keychain API refactor
---------
Co-authored-by: electron-roller[bot] <84116207+electron-roller[bot]@users.noreply.github.com>
Co-authored-by: Keeley Hammond <khammond@slack-corp.com>
Co-authored-by: Samuel Maddock <samuelmaddock@electronjs.org>
Co-authored-by: clavin <clavin@electronjs.org>
(cherry picked from commit a65cfed500)
* chore: update patches after rebase
---------
Co-authored-by: electron-roller[bot] <84116207+electron-roller[bot]@users.noreply.github.com>
Co-authored-by: Keeley Hammond <khammond@slack-corp.com>
Co-authored-by: Samuel Maddock <samuelmaddock@electronjs.org>
Co-authored-by: clavin <clavin@electronjs.org>
Co-authored-by: John Kleinschmidt <kleinschmidtorama@gmail.com>
