fix: ensure corsEnabled: false protocol handlers do not work across protocols (#51152)
* fix: ensure corsEnabled: false protocol handlers do not work across protocols
Subresource requests for registered custom protocols are routed to
ElectronURLLoaderFactory via the renderer's per-scheme URLLoaderFactoryBundle
entry, which bypasses the network service's CorsURLLoaderFactory. This meant a
cross-origin page could fetch() a scheme registered with {supportFetchAPI: true}
and read the response body even when {corsEnabled: true} was not set.
Replicate CorsURLLoader::StartRequest's kCorsDisabledScheme gate in
ElectronURLLoaderFactory::CreateLoaderAndStart so cross-origin mode=cors
requests to such schemes fail before the JS handler runs, and tag cross-origin
mode=no-cors responses as opaque so the body is not script-readable while <img>
and similar subresource loads continue to work.
Re-enable the long-disabled "disallows CORS and fetch requests when only
supportFetchAPI is specified" test, add coverage for the opaque/no-cors,
same-origin, handler-not-invoked, corsEnabled-unaffected and net.fetch-unaffected
cases, and migrate spec helpers that were exercising a {supportFetchAPI: true}
scheme cross-origin to a corsEnabled scheme.
* chore: oxfmt
(cherry picked from commit 92f0993d94)
build: don't use //third_party/depot_tools in lint.js (#51034)
* build: don't use //third_party/depot_tools in lint.js
* chore: also run python3 through depot tools
* feat: add `Notification.getHistory()` static method (macOS)
Add `Notification.getHistory()` which returns a `Promise<Notification[]>`
of all delivered notifications still present in Notification Center.
Each returned Notification is a live object connected to the corresponding
delivered notification — interaction events (click, reply, action, close)
will fire on these objects, enabling apps to re-attach event handlers after
a restart.
Key implementation details:
- Queries UNUserNotificationCenter's getDeliveredNotifications API
- Creates live Notification objects with populated id, groupId, title,
subtitle, and body properties from what macOS provides
- Registers each object with the presenter via Restore() so the
NotificationCenterDelegate routes events correctly
- Restored notifications use is_restored_ flag to prevent removal from
Notification Center when the JS object is garbage collected
- Requires code-signed builds (unsigned builds resolve with empty array)
Co-Authored-By: Claude <svc-devxp-claude@slack-corp.com>
Co-authored-by: Keeley Hammond <khammond@slack-corp.com>
* test: fix typecheck
Co-authored-by: Keeley Hammond <vertedinde@electronjs.org>
* fix: avoid dangling presenter pointer in GetHistory callback
Co-authored-by: Keeley Hammond <khammond@slack-corp.com>
* fix: document show() behavior
Notifications returned by getHistory() now set is_restored_ so that Dismiss() skips removal from Notification Center on GC. Calling show() on a restored notification removes the original from NC and posts a new one.
Co-authored-by: Keeley Hammond <khammond@slack-corp.com>
* fix: address code review feedback
Co-authored-by: Keeley Hammond <khammond@slack-corp.com>
* test: fix oxfmt linting
Co-authored-by: Keeley Hammond <khammond@slack-corp.com>
* docs: update docs/api/notification.md
Co-authored-by: Erick Zhao <erick@hotmail.ca>
Co-authored-by: Keeley Hammond <vertedinde@electronjs.org>
---------
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Keeley Hammond <khammond@slack-corp.com>
Co-authored-by: Keeley Hammond <vertedinde@electronjs.org>
fix: ignore draggable regions in hidden WebContentsView
Hidden child WebContentsViews were still contributing their draggable
regions to the parent window's non-client hit test, so clicks in the
area where a hidden view's draggable element would render still dragged
the window. Early-return HTNOWHERE when the view is not visible.
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Shelley Vohr <shelley.vohr@gmail.com>
fix: FTBFS when pdf is disabled
pdf_features.h has a static_assert that pdf is enabled
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Charles Kerr <charles@charleskerr.com>
* chore: remove calls to DeprecatedLayoutImmediately
Replace the calls to `DeprecatedLayoutImmediately` that have test
coverage.
- The docked DevTools test added last week covers the three calls in IWCV.
- api-web-contents-view-spec covers the calls from NativeWindow{Views,Mac}.
There are a couple of remaining calls that don't have test coverage yet.
I'll get to them in a followup.
* test: handle both sync or microtask layout
* refactor: add a FlushPendingRootLayout() helper
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Charles Kerr <charles@charleskerr.com>
fix: reset printToPDF queue after a rejection
The module-scoped `pendingPromise` in `webContents.printToPDF` was chained
with `.then(onFulfilled)` and never cleared. Once a call rejected (e.g.
an out-of-range `pageRanges` like `"999"`), subsequent calls chained onto
the rejected promise and short-circuited without ever invoking
`_printToPDF` — so every following call re-surfaced the original error.
Replace the shared variable with a per-`WebContents` `WeakMap` queue that
swallows prior rejections before chaining and clears its entry once the
tail drains.
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Shelley Vohr <shelley.vohr@gmail.com>
* build: use Yarn JsZipImpl for node-modules link step
Patch the vendored .yarn/releases/yarn-4.12.0.cjs so the node-modules
(and pnpm-loose) linker constructs its read-only ZipOpenFS with
customZipImplementation = JsZipImpl instead of the default WASM
LibZipImpl.
LibZipImpl loads each cache zip fully into the Emscripten WASM heap and
malloc's a WASM buffer per file read. With up to 80 zips held open, the
32-bit arm32v7 test container intermittently fails to allocate the ~9 MB
buffer for typescript/lib/typescript.js. Yarn's cross-FS copyFilePromise
swallows the real error and surfaces it as a generic
"EINVAL: invalid argument, copyfile", which has been failing ~1-in-3
linux-arm test shards at Install Dependencies since 2026-04-13.
JsZipImpl opens zips by fd, reads only the central directory, and pulls
individual entries into plain Node Buffers — no WASM heap involved.
There is no .yarnrc.yml or env knob for this, so the vendored release is
edited directly. .claude/README.md documents the patch and how to
re-apply it on Yarn upgrades.
Refs: yarnpkg/berry#3972, yarnpkg/berry#6722, yarnpkg/berry#6550
Co-authored-by: Sam Attard <sattard@anthropic.com>
* docs: move JsZipImpl patch notes to .yarn/README.md
Relocate the patch rationale next to the vendored release it documents,
reword the intro for its new home, and update the header comment in
yarn-4.12.0.cjs to point at .yarn/README.md.
Co-authored-by: Sam Attard <sattard@anthropic.com>
---------
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Sam Attard <sattard@anthropic.com>
After #49428 made `NativeWindowViews::CanResize()` return `resizable_`
for frameless windows (instead of `resizable_ && thick_frame_`),
`HWNDMessageHandler::SizeConstraintsChanged()` started adding
`WS_THICKFRAME` to the window style whenever `CanResize()` reported true.
`WS_THICKFRAME` is incompatible with layered (translucent) windows and
destroys their transparency.
`SetContentSizeConstraints` already guards against this by skipping
`OnSizeConstraintsChanged()` when `!thick_frame_`. `SetResizable` did
not, so toggling resizability on a transparent window (e.g.
`setResizable(false)` then `setResizable(true)`) caused the Chromium
path to add `WS_THICKFRAME` and strip transparency.
Apply the same guard in `SetResizable`. Min/max constraints are still
enforced — Chromium reads them from the widget delegate on every
`WM_GETMINMAXINFO`, independent of `SizeConstraintsChanged()`.
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Shelley Vohr <shelley.vohr@gmail.com>
* test: add Linux-specific test for getApplicationNameForProtocol()
On Linux, use XDG env vars to inject a mock that we can use
to test app.getApplicationNameForProtocol().
Co-authored-by: Charles Kerr <charles@charleskerr.com>
* fixup! test: add Linux-specific test for getApplicationNameForProtocol()
better system mocks
Co-authored-by: Charles Kerr <charles@charleskerr.com>
* chore: make lint happy
---------
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Charles Kerr <charles@charleskerr.com>
Co-authored-by: David Sanders <dsanders11@ucsbalum.com>
* fix: trigger ShipIt Mach service to unblock on-demand-only mode
When a macOS system update is pending, launchd puts the user domain
into on-demand-only mode, preventing ShipIt from starting. The
MachServices endpoint in the job dictionary was registered but never
connected to (a leftover from the XPC removal in 2013).
Instead of removing MachServices, fire a lightweight XPC connection
to the Mach port after SMJobSubmit. This satisfies launchd's
on-demand trigger, starting ShipIt immediately while preserving
KeepAlive retry behavior.
Co-Authored-By: Claude <svc-devxp-claude@slack-corp.com>
Co-authored-by: Keeley Hammond <khammond@slack-corp.com>
* fix: add ResetAtClose to ShipIt MachServices to prevent standing demand
The XPC trigger message sent after SMJobSubmit sits in the Mach port's
kernel queue unread. Without ResetAtClose, this creates standing demand
that causes launchd to respawn ShipIt after a successful exit(0),
defeating KeepAlive.SuccessfulExit = NO.
Set ResetAtClose on the MachServices registration so launchd tears down
and recreates the port when ShipIt exits, flushing the stale trigger.
Co-Authored-By: Claude <svc-devxp-claude@slack-corp.com>
Co-authored-by: Keeley Hammond <khammond@slack-corp.com>
* fix: drain Mach port before exit(0) instead of using ResetAtClose
ResetAtClose blocks KeepAlive.SuccessfulExit retries in on-demand-only
mode because it removes demand when the port resets. Instead, have
ShipIt drain its own Mach service port (via bootstrap_check_in +
mach_msg) before each exit(EXIT_SUCCESS). This clears the standing
demand from the trigger message so launchd won't respawn after a
successful exit, while leaving the message in place on failure exits
so KeepAlive retries remain demand-backed.
Tested in on-demand-only mode (pending macOS update):
- exit(0) + drain: 1 run, no respawn ✓
- exit(1) + no drain: continuous respawn every 2s ✓
Co-Authored-By: Claude <svc-devxp-claude@slack-corp.com>
Co-authored-by: Keeley Hammond <khammond@slack-corp.com>
* chore: update patch
Co-authored-by: Keeley Hammond <khammond@slack-corp.com>
* chore: harden ShipIt Mach trigger and simplify port drain
Scope the XPC trigger to the unprivileged path and add a send barrier
so the connection cannot be released before the message is on the wire.
Reduce drainMachServicePort to bootstrap_check_in (process exit flushes
the queue), dropping the mach_msg loop whose buffer/dealloc usage was
incorrect, and remove the no-op drain from the posix_spawn'd launch
helper. Patch filename regenerated to match the commit subject.
Co-authored-by: Samuel Attard <sattard@anthropic.com>
* fix: restore explicit mach_msg drain in drainMachServicePort
bootstrap_check_in alone does not prevent respawn: launchd tracks
outstanding demand independently of the receive right's lifetime, so the
queued trigger message must be explicitly dequeued with mach_msg before
exit(0). Verified empirically (check-in-only: 5 respawns in 10s; full
drain: 1 run). Keep the correctness fixes from the previous commit
(4K buffer, mach_msg_destroy on each receive, no mach_port_deallocate).
Co-authored-by: Samuel Attard <sattard@anthropic.com>
---------
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Keeley Hammond <khammond@slack-corp.com>
Co-authored-by: Samuel Attard <sattard@anthropic.com>
On ARM64 Windows, UnregisterSuspendResumeNotification (user32) forwards
to PowerUnregisterSuspendResumeNotification (powrprof), which treats the
HPOWERNOTIFY handle as a pointer and dereferences it. The user32 API
returns an opaque handle, not a pointer-backed allocation, causing an
access violation at shutdown.
Add crash keys (pm-reg-handle, pm-reg-memstate, pm-unreg-memstate) to
capture
- The handle value
- VirtualQuery memory state at both registration and unregistration
If the handle address is MEM_FREE, it confirms the handle is an opaque
index and powrprof is incorrectly dereferencing it. If MEM_COMMIT, it
would indicate a use-after-free of the underlying allocation.
Refs https://github.com/MicrosoftDocs/sdk-api/blob/docs/sdk-api-src/content/powerbase/nf-powerbase-powerunregistersuspendresumenotification.md
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: deepak1556 <hop2deep@gmail.com>
* chore: bump node in DEPS to v24.15.0
* fix(patch): adapt V8 sandboxed pointers for buffer kMaxLength
Upstream replaced the hardcoded buffer length limit with a runtime
kMaxLength variable, making the patch's regex workaround for sandbox
vs non-sandbox limits unnecessary. Dropped the test-buffer-concat.js
hunk.
Ref: https://github.com/nodejs/node/pull/61721
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* fix(patch): adapt deprecated GetIsolate for upstream refactors
Upstream removed Uint32ToName from node_contextify.cc and
node_webstorage.cc, and renamed LookupAndCompile to
LookupAndCompileFunction in node_builtins.cc. Updated the
GetIsolate deprecation patch to match.
Ref: https://github.com/nodejs/node/pull/60846
Ref: https://github.com/nodejs/node/pull/60518
* chore: remove upstreamed patch
The fix_generate_config_gypi_needs_to_generate_valid_json patch
applied with "No changes -- Patch already applied", confirming
the fix has been incorporated upstream.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* node#60518: src: build v8 tick processor as built-in source text modules
Upstream restructured BuiltinLoader to auto-detect parameters by
source type, removing the custom parameters overload. Added a new
LookupAndCompileFunction overload for embedder scripts and updated
node_util.cc to use it. Also suppressed exit-time-destructors
warning from builtin_info.h in node_includes.h.
Ref: https://github.com/nodejs/node/pull/60518
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* fix(patch): add LookupAndCompileFunction overload for embedder scripts
Ref: https://github.com/nodejs/node/pull/60518
* fix(patch): stop using v8::PropertyCallbackInfo<T>::This() in sqlite
Ref: https://github.com/nodejs/node/issues/60616
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* fix(patch): adapt new crypto tests for BoringSSL
Guard aes-128-ccm test in test-crypto-authenticated.js behind cipher
availability check. Skip Ed448/X448/DSA tests in
test-crypto-key-objects-raw.js. Skip AES-KW tests in
test-webcrypto-promise-prototype-pollution.mjs.
Ref: https://github.com/nodejs/node/pull/62240
Ref: https://github.com/nodejs/node/pull/62455
* fix(patch): guard DH key test for BoringSSL
BoringSSL does not support loading DH private keys from PEM, causing
createPrivateKey to throw UNSUPPORTED_ALGORITHM.
Ref: https://github.com/nodejs/node/pull/62240
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* fix(patch): correct thenable snapshot for Chromium V8
The snapshot used `*` wildcards which don't match the actual output.
Regenerated with NODE_REGENERATE_SNAPSHOTS=1 to capture the correct
concrete frame + <node-internal-frames> output.
Ref: https://chromium-review.googlesource.com/c/v8/v8/+/6826001
* fix(patch): GN build files for new merve dep
Ref: https://github.com/nodejs/node/pull/61984
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* fix(patch): adapt fileExists patch to resolve.js module reorg
Ref: https://github.com/nodejs/node/pull/61769
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* chore: update patches (trivial only)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: electron-roller[bot] <84116207+electron-roller[bot]@users.noreply.github.com>
Co-authored-by: Shelley Vohr <shelley.vohr@gmail.com>
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* fix: intermittent CI failure is-not-alwaysOnTop
Ensure that the `always-on-top-changed` event always fires with the
right 'alwaysOnTop' boolean, regardless of interaction between
SetZOrderLevel() and MoveBehindTaskBarIfNeeded(). We know what the
value will be when all of the HWND events settle, so use that value.
Co-authored-by: Charles Kerr <charles@charleskerr.com>
* test: temporary commit to torture-test the new change with 1000 iterations
Co-authored-by: Charles Kerr <charles@charleskerr.com>
* test: keep eventually-becomes-consistent test but do not loop 1000 times
Co-authored-by: Charles Kerr <charles@charleskerr.com>
---------
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Charles Kerr <charles@charleskerr.com>
Clone angle from github.com/google/angle in fix-sync action
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Claude <noreply@anthropic.com>
BUILD.gn previously hard-coded read_file(".git/packed-refs", ...) and
".git/HEAD" to derive electron_version. In a `git worktree` checkout
.git is a file containing a gitdir: pointer, not a directory, so GN's
read_file() fails and gn gen aborts unless override_electron_version is
set manually.
Ask git itself for the real locations via `git rev-parse --git-dir` /
`--git-common-dir` in a small helper script, and feed those resolved
paths to read_file() and the exec_script dependency list. Behaviour in
a plain clone is unchanged (both resolve to electron/.git/...), and the
tarball case still fails loudly with a pointer to
override_electron_version.
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Sam Attard <sattard@anthropic.com>
stop_dbus() was removed on 2025-09-14 by
99c4800e9e
I think CI isn't seeing this yet because its image has an older version.
This patched script should work on old & new versions of python-dbusmock.
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Charles Kerr <charles@charleskerr.com>
* ci: build a patched siso for Windows builds
The Windows Chromium builds intermittently fail during manifest load
with 'The parameter is incorrect.' (ERROR_INVALID_PARAMETER) out of
bindflt.sys. Root cause is a handle-relative NtCreateFile race in
siso/toolsupport/ninjautil/file_parser.go, which opens each subninja
twice — once in the outer goroutine and once more per chunk for
ReadAt. (*os.File).ReadAt is documented as safe for concurrent use,
so the extra open is redundant and removing it both halves the
CreateFileW calls per subninja and sidesteps the race.
Add a new build-siso-windows job on ubuntu-latest (runs in parallel
with checkout-windows) that:
- reads chromium_version from DEPS and pulls the matching siso_version
SHA from the Chromium mirror's DEPS at that ref
- shallow-clones chromium.googlesource.com/build at that SHA
- applies the in-tree patches under .github/siso-patches/ via git am
- cross-compiles siso.exe for windows/amd64
- caches the binary keyed on siso SHA + sha256 of the patches, so
subsequent runs hit the cache and skip the clone/patch/build steps
- uploads the result as a siso-windows-amd64 artifact
The Windows build jobs now depend on build-siso-windows, download the
artifact into $RUNNER_TEMP/siso, and export SISO_PATH, which
depot_tools/siso.py already honors. Mirrored into windows-publish.yml
and the regenerated pipeline-segment-electron-publish.yml so release
builds pick it up too.
Notes: none
Co-authored-by: Sam Attard <sattard@anthropic.com>
* ci: extract siso build into a reusable workflow segment
Move the build-siso-windows job body into
pipeline-segment-build-siso-windows.yml and call it from both build.yml
and windows-publish.yml via workflow_call. Also pin actions/cache to
v5.0.5 and add version comments next to the action SHAs introduced by
this change.
Co-authored-by: Sam Attard <sattard@anthropic.com>
---------
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Sam Attard <sattard@anthropic.com>
Because of a bug after the [upstream refactor][0] Dev Tools stopped
showing 'Electron Isolated Context' in the execution context selector.
'Electron Isolated Context' runs with origin set to `file://`. Since
domain name is empty for the origin the respective UI item in the
context selector is created with an empty `subtitle`. However, with the
upstream change items with either of `title` or `subtitle` are omitted
from rendering.
Here we float an [in-review patch][1] until it is fixed upstream.
[0]: dbb61cf4b2
[1]: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/7761316
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Fedor Indutny <indutny@signal.org>
fix: prevent use-after-free when destroying guest WebContents during event emission
Multiple event emission sites in WebContents destroy the underlying C++
object via a JavaScript event handler calling webContents.destroy(), then
continue to dereference the freed `this` pointer. This is exploitable
through <webview> guest WebContents because Destroy() calls `delete this`
synchronously for guests, unlike non-guests which safely defer deletion.
The fix has two layers:
1. A new `is_emitting_event_` flag is checked in Destroy() — when true,
guest deletion is deferred to a posted task instead of executing
synchronously. This is separate from `is_safe_to_delete_` (which
gates LoadURL re-entrancy) to avoid rejecting legitimate loadURL
calls from event handlers.
2. AutoReset<bool> guards on `is_emitting_event_` are added to
CloseContents, RenderViewDeleted, DidFinishNavigation, and
SetContentsBounds, preventing synchronous destruction while their
Emit() calls are on the stack.
Destroy() now requires both `is_safe_to_delete_` (navigation re-entrancy)
and `!is_emitting_event_` (event emission) to allow synchronous guest
deletion. The existing AutoReset guards on `is_safe_to_delete_` in
DidStartNavigation, DidRedirectNavigation, and ReadyToCommitNavigation
are also now effective for guests.
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Shelley Vohr <shelley.vohr@gmail.com>
The PDF viewer's "save with changes" feature uses
`window.showSaveFilePicker()`, but the PDF extension runs in a
cross-origin iframe (chrome-extension:// inside the app's origin).
Chromium's File System Access API blocks cross-origin subframes from
showing file pickers unless the embedder explicitly allows them via
`ContentClient::IsFilePickerAllowedForCrossOriginSubframe()`.
Chrome overrides this in `ChromeContentClient` to allowlist the PDF
extension origin, but Electron never did — so the picker was always
blocked with a SecurityError.
This adds the same override to `ElectronContentClient`, allowing the
built-in PDF extension origin to bypass the cross-origin check.
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Shelley Vohr <shelley.vohr@gmail.com>
fix: fail gha-done when any required job failed
Previously, the `gha-done` gate job used an `if:` expression that
evaluated to false whenever any needed job reported a failure, which
caused the job to be *skipped* rather than *failed*. GitHub branch
protection treats skipped required checks as non-blocking, so a PR
could be marked mergeable even though one of its test jobs had failed.
Keep the job always running and move the failure check into a step
that explicitly exits 1 when any dependency failed or was cancelled,
so the "GitHub Actions Completed" required check actually blocks the
merge in that case.
Notes: none
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Samuel Attard <samuel.r.attard@gmail.com>
chore: remove dead patches from chore_provide_iswebcontentscreationoverridden_with_full_params.patch
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Charles Kerr <charles@charleskerr.com>
* ci: don't login to RBE for clang-tidy
Co-authored-by: John Kleinschmidt <kleinschmidtorama@gmail.com>
* ci: don't login to RBE for gn check
Co-authored-by: John Kleinschmidt <kleinschmidtorama@gmail.com>
---------
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: John Kleinschmidt <kleinschmidtorama@gmail.com>
chore: do not patch files we do not use
do not patch fake_desktop_media_list.cc, .h
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Charles Kerr <charles@charleskerr.com>
* fix: nodeIntegrationInWorker not working in AudioWorklet
Co-authored-by: Shelley Vohr <shelley.vohr@gmail.com>
* fix: deadlock on Windows when destroying non-AudioWorklet worker contexts
The previous change kept the WebWorkerObserver alive across
ContextWillDestroy so the worker thread could be reused for the next
context (AudioWorklet thread pooling, Chromium CL:5270028). This is
correct for AudioWorklet but wrong for PaintWorklet and other worker
types, which Blink does not pool — each teardown destroys the thread.
For those worker types, ~NodeBindings was deferred to the thread-exit
TLS callback. By that point set_uv_env(nullptr) had already run, so on
Windows the embed thread was parked in GetQueuedCompletionStatus with a
stale async_sent latch that swallowed the eventual WakeupEmbedThread()
from ~NodeBindings. uv_thread_join then blocked forever, deadlocking
renderer navigation. The worker-multiple-destroy crash case timed out
on win-x64/x86/arm64 as a result. macOS/Linux (epoll/kqueue) don't have
the latch and were unaffected.
Plumb is_audio_worklet from WillDestroyWorkerContextOnWorkerThread into
ContextWillDestroy. For non-AudioWorklet contexts, restore the
pre-existing behavior of calling lazy_tls->Set(nullptr) at the end of
the last-context cleanup so ~NodeBindings runs while the worker thread
is still healthy. AudioWorklet continues to keep the observer alive so
the next pooled context can share NodeBindings.
Co-authored-by: Shelley Vohr <shelley.vohr@gmail.com>
* chore: address review feedback
Co-authored-by: Shelley Vohr <shelley.vohr@gmail.com>
* fix: stop embed thread before destroying environments in worker teardown
FreeEnvironment (called via environments_.clear()) runs uv_run to drain
handle close callbacks. On Windows, both that uv_run and the embed
thread's PollEvents call GetQueuedCompletionStatus on the same IOCP
handle. IOCP completions are consumed by exactly one waiter, so the
embed thread can steal completions that FreeEnvironment needs, causing
uv_run to block indefinitely. On Linux/Mac epoll_wait/kevent can wake
multiple waiters for the same event so the race doesn't manifest.
Add NodeBindings::StopPolling() which cleanly joins the embed thread
without destroying handles or the loop, and allows PrepareEmbedThread +
StartPolling to restart it later. Call StopPolling() in
WebWorkerObserver::ContextWillDestroy before environments_.clear() so
FreeEnvironment's uv_run is the only thread touching the IOCP.
Split PrepareEmbedThread's handle initialization (uv_async_init,
uv_sem_init) from thread creation via a new embed_thread_prepared_ flag
so the handles survive across stop/restart cycles for pooled worklets
while the embed thread itself can be recreated.
Co-authored-by: Shelley Vohr <shelley.vohr@gmail.com>
* chore: address outstanding feedback
Co-authored-by: Shelley Vohr <shelley.vohr@gmail.com>
---------
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Shelley Vohr <shelley.vohr@gmail.com>
