* docs: note beta.1 waits for the Chromium roll
The Releases WG moved alpha-to-beta promotion to release automation,
gated on the release branch's Chromium reaching the version in Chrome's
Beta channel. beta.1 is no longer a fixed date, so stop listing it as one
of our solid release dates and note it can land a few days late.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AmPhpNhEFuPd7juZ3fc781
* docs: explain beta.1 delay without roll jargon
Say plainly that beta.1 can be late when the release branch has not yet
been updated to the Chromium Beta-channel version, instead of referring
to "our Chromium roll" without explaining it.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AmPhpNhEFuPd7juZ3fc781
* docs: link Chrome's Beta channel in release timeline
Link to Chromium's release channel page and briefly explain that the
Beta channel is where each Chrome version is tested for about four weeks
before stable.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AmPhpNhEFuPd7juZ3fc781
* docs: clarify which release dates are fixed
Replace "our solid release dates" with plain wording: alpha.1 and stable
ship on the scheduled dates, while the prereleases in between, including
beta.1, don't have fixed dates.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AmPhpNhEFuPd7juZ3fc781
* docs: tighten beta.1 timing note
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AmPhpNhEFuPd7juZ3fc781
* docs: use canonical Chrome release channels URL
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AmPhpNhEFuPd7juZ3fc781
---------
Co-authored-by: Claude <noreply@anthropic.com>
* refactor: give WebContentsView a native view of its own
A WebContentsView used its webContents InspectableWebContentsView as its
native view. The webContents owns that view and deletes it along with
itself, so a WebContentsView could outlive its native view and every View
method had to check for a null view.
WebContentsViewHost now owns a container view for the whole life of the
WebContentsView and presents the inspectable view in it, filling it, as
its last child. Child views added from JavaScript stay before it and so
beneath the page, as they were when added to the inspectable view. With
that, View::Host always owns its view, and the unowned mode goes away.
Ownership of the webContents no longer needs a user-data claim. The host
whose container presents the inspectable view owns it. Adopting a
webContents in a new WebContentsView moves the inspectable view into the
new container, so only that view acts on the webContents and destroys it
when collected. Two WebContentsViews that share a webContents are now
separate children, rather than one native view tracked twice.
* fix: update the overlay when a WebContentsView moves
Since a WebContentsView has its own container view, moving it without
resizing leaves the page view's bounds unchanged, so the window controls
overlay was never re-sent to the page.
* feat: add app.isUnnecessarilyElevated() and a deElevate option to app.relaunch() on Windows
An Electron app started with a full administrator token while UAC is
enabled cannot always launch its sandboxed child processes (the sandbox
broker's CreateProcessAsUser fails under some enterprise policies,
surfacing as render-process-gone launch-failed with exit code 18 or a
blank window), and app code that was never meant to run elevated does.
Chrome handles this by relaunching itself de-elevated at startup.
Give apps the same option: app.isUnnecessarilyElevated() reports whether
the process holds an elevated split token, and app.relaunch({ deElevate:
true }) makes the relauncher start the new instance through
base::win::RunDeElevated() with the user's normal token.
* fix: carry the RunDeElevated working directory fix so a de-elevated relaunch keeps its cwd
* refactor: rename to app.canDeElevate()
* fix: launch the de-elevated relaunch through RunDeElevatedNoWait so it keeps the working directory without a base patch
https://chromium-review.googlesource.com/c/chromium/src/+/8401888 added
ui::NativeTheme::SetPreferredColorSchemeOverride(), which does what the
set_theme_source() patch did, for every theme instance at once. Use it and
drop the patch. themeSource keeps its own stored value, and "system"
restores the override the process started with, so that --force-dark-mode
behaves as before.
* refactor: migrate View, ImageView and WebContentsView to cppgc
The View wrappers were gin_helper::EventEmitter objects, and every edge
between them was a strong V8 root. A parent held each child in a
v8::Global, BaseWindow and BrowserWindow held their content view in a
v8::Global, and WebContentsView held its WebContents in a
cppgc::Persistent. A view reachable only through such a cycle, such as
a layout callback that closes over its own view, was never collected.
The wrappers are now cppgc managed gin::Wrappables, and those edges are
traced:
- Children are kept in a traced list of child entries, matched by their
native views::View so that two WebContentsViews sharing a webContents
stay distinct.
- The layout callback is a v8::TracedReference; the layout manager only
holds a WeakPtr to the native side.
- WebContentsView holds its WebContents with a Member.
- BaseWindow and BrowserWindow root their views with cppgc::Persistent
while the native window uses them.
Native state moves to View::Host, a NativePeer that owns or observes the
views::View and is torn down through Release(), never from a GC
destructor. WebContentsViewHost additionally holds the WebContents,
window and draggable-region observers and the overlay update. A
user-data claim on content::WebContents records which host owns the
webContents, so a view that adopts the webContents of a collected but
not yet released view is not destroyed with it. The claim is checked and
the webContents disposed in the same task through the new
WebContents::DestroyNow(). At shutdown, hosts leave disposal to the
WebContents itself.
ImageView and WebContentsView keep their own WrapperInfos and share one
kElectronView pointer tag, and Converter<View*> accepts all three.
gin_helper::Constructible gains ConstructibleParent, so a subclass
constructor template inherits View's, and BindToConstructCall, so
`class extends` and Reflect.construct keep the subclass prototype.
* chore: fix lint
UsbChooserContextFactory did not override GetBrowserContextToUse(), so
off-the-record contexts got no UsbChooserContext and the chooser
controller dereferenced null. Give in-memory sessions their own context,
as the HID and serial factories do.
Refactors the non-shareable window filtering in the Chromium
ScreenCaptureKit patch:
1. Extracts inline NSWindowSharingNone filtering into a reusable
GetNonShareableWindows() helper function.
2. Fixes a bug where content-protected windows (via
win.setContentProtection(true)) could temporarily appear in screen
captures during picture-in-picture state changes — the PiP filter
update handler was only excluding PiP windows, not non-shareable
ones.
Notes: Fixed a bug where content-protected windows could temporarily appear in screen captures during picture-in-picture state changes.
* test: add Windows mouse-input addon for setIgnoreMouseEvents specs
Adds @electron-ci/mouse-input, a Windows-only native test addon that
injects real mouse input with SendInput(). Unlike
webContents.sendInputEvent() these events go through the WH_MOUSE_LL
hook that setIgnoreMouseEvents(true, { forward: true }) relies on.
Uses it for serial specs covering click-through, forwarding of moves,
mouseenter/mouseleave stability inside an element and :hover being
cleared when the cursor moves off an element. On CI the suite fails
instead of skipping when SendInput cannot inject input.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y5cq8qhU8xUitP6SzyT2FV
* test: extend mouse-input addon to macOS and Linux X11
Adds CGEventPost (macOS) and XTEST (Linux X11, dlopen()ed so no dev
headers are needed) backends behind the existing JS API and generalizes
the setIgnoreMouseEvents real-input spec: hit testing on Windows and X11,
click-through on all three, forwarding cases on macOS and Windows only.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y5cq8qhU8xUitP6SzyT2FV
* ci: install libXtst in Linux test jobs that lack it
The mouse-input spec addon loads libXtst.so.6 at runtime for XTEST. The
x64 build image ships it but the arm64 test image does not, so install
the runtime package there before running the specs.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y5cq8qhU8xUitP6SzyT2FV
* ci: dismiss the first sign-in privacy window on Windows test runners
The windows-11-arm image shows Windows' "Choose privacy settings for
your device" window full screen above even topmost windows, so real
mouse input clicked it instead of the windows under test and the OS hit
tested it at the test point (seen in the mouse-input spike's
screenshots). Stop UserOOBEBroker/WWAHost and set the policies that keep
it from coming back, logging the windows on screen before and after.
Add describeWindowAtPoint() to the Windows addon backend and report it
when the hit test or click-through cases time out, so a covering window
is named in the failure.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y5cq8qhU8xUitP6SzyT2FV
* ci: also close the Start menu on Windows test runners
With the first sign-in privacy window gone, windows-11-arm had the Start
menu open over the test area: describeWindowAtPoint() reported its
CoreWindow at the hit test point, and the click-through case's click then
launched Calculator from it, which covered the point for the retries.
Stop StartMenuExperienceHost (it restarts with the menu closed) and log
what the OS hit tests on screen afterwards.
Before clicking, the click-through case now waits for the window below to
be what the OS hit tests at the point, where the platform can say, so a
covering window fails the case with its name instead of taking the click.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y5cq8qhU8xUitP6SzyT2FV
* test: keep ordinary windows from covering the click-through case
On windows-11-arm the runner's terminal (a Windows Terminal window
running wsl.exe) came up over the non-topmost window below after the
cleanup step ran, so the case's hit test check found it there. Make the
window below topmost too; the ignoring window is shown after it and
stays above it.
The cleanup step also found a System Properties dialog left at the
centre of the screen, so it now minimizes (dialogs: closes) every
visible, uncloaked top level window besides the desktop and taskbar
and logs each one, rather than stopping known processes only.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y5cq8qhU8xUitP6SzyT2FV
* ci: close the Start menu with Escape instead of stopping its host
Stopping StartMenuExperienceHost on the Windows test runners was followed
by WebContentsView visibilityState specs reading 'hidden' on
windows-11-arm in both runs that did it, and in none before. Only press
Escape when the Start menu's CoreWindow is actually showing (uncloaked),
and log its state.
Clearing the desktop now repeats until nothing is left: closing the
leftover System Properties dialog left its Performance Options dialog
over the test area.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y5cq8qhU8xUitP6SzyT2FV
* ci: sample window occlusion inputs during Windows specs (diagnostic)
With the Start menu closed on windows-11-arm, api-web-contents-view.spec.ts
sees freshly shown windows as hidden for a while (3 of 3 runs). Log the
display, screen saver and power request settings and the WSL/terminal
processes, then run a background sampler that records, whenever it changes,
the foreground window and any window able to occlude Electron's that sits
above the topmost Electron window, plus display on/off and session lock
changes. Its log is printed after the specs.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y5cq8qhU8xUitP6SzyT2FV
* ci: stop the windows-11-arm WSL update from covering the specs
The occlusion sampler showed what hides api-web-contents-view.spec.ts's
windows on windows-11-arm: the image runs
`wsl.exe --update --confirm --prompt-before-exit` and relaunches it about
every 90 seconds, each time in a new Windows Terminal window that takes the
foreground over most of the 1024x768 desktop for about a minute, so
Chromium's native occlusion tracking reports Electron windows beneath it as
hidden. The display never turned off (no display timeout on AC, display
status stayed on), so that is ruled out.
Log what launches the update, stop it (and its launcher when that is a
script host outside the step's own ancestry), and have the sampler minimize
any such window that still shows up.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y5cq8qhU8xUitP6SzyT2FV
* ci: trim the Windows occlusion sampler down to a WSL terminal minimizer
The sampler found what hid api-web-contents-view.spec.ts's windows on
windows-11-arm; drop its diagnostic sampling and the power and screen saver
dumps, and keep only what fixes it: a background minimizer, now
script/actions/minimize-wsl-terminals.ps1, that minimizes each
`wsl.exe --update` terminal as it appears and logs its title, pid and
parent process, printed after the specs.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y5cq8qhU8xUitP6SzyT2FV
---------
Co-authored-by: Claude <noreply@anthropic.com>
* build: bound devtools-frontend esbuild bundle concurrency on macOS
macOS x64 release builds have been failing in Build Electron when
devtools-frontend esbuild bundle actions die with "The service was
stopped": the esbuild service process is killed externally with no
crash trace, consistent with memory pressure on the 14 GB
macos-15-xlarge runners while siso runs five minify+sourcemap bundles
at once through the generic action pool.
Float a devtools-frontend patch that gives esbuild bundle actions their
own GN pool (depth 2 on macOS hosts), and dump vm_stat, swap usage and
the kernel memorystatus/jetsam log when a macOS build fails so the kill
is observable.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H2pb2QXCU6xBfNMLmjgrLU
* chore: update patches
Refresh the devtools-frontend BUILD.gn blob ids in the esbuild pool patch
after the Chromium roll on main moved the devtools-frontend pin. No change
to the patch content.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H2pb2QXCU6xBfNMLmjgrLU
* ci: drop esbuild pool patch, keep macOS memory diagnostics only
Scope this change down to the failure-only macOS memory-pressure
diagnostics step so we can confirm or rule out memory pressure as the
cause of the intermittent devtools esbuild failures before patching
devtools-frontend.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01U8eWCdgZ42Hdi8CMcrcrNb
---------
Co-authored-by: Claude <noreply@anthropic.com>
* test: listen for both singleton exits before either can happen
'prevents the second launch of app' only started listening for the first
instance's 'exit' after the second instance's exit had been handled. The
two copies quit within milliseconds of each other, so when the spec
process's event loop is busy and sees both exits in the same pass, the
first copy's 'exit' is emitted with no listener, and the test then waits
for it until the 120s test timeout.
Register both exit listeners as each process is spawned, as the other
requestSingleInstanceLock tests already do, kill both copies on the way
out, and fail within 30s naming which copy stalled instead of waiting
out the test timeout.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XT1kpjmqsAdPLBVZMV1pVX
* test: use waitUntil for the singleton launch waits
Record each copy's exit code from an 'exit' listener attached at spawn
and wait on it with the existing waitUntil helper instead of a local
within() helper. Only kill a copy that is still running.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XT1kpjmqsAdPLBVZMV1pVX
---------
Co-authored-by: Claude <noreply@anthropic.com>
* docs: document how to deny a display media request
* test: make the webview printToPDF() bad parameter spec reach the type checks
The spec loaded another <webview id="webview"> on every pass of its loop, so
from the second pass on `webview` named a collection of elements and the call
was rejected with "webview.printToPDF is not a function". Only the first of
the ten parameters was checked. Load the webview once, and require the
rejection to name the parameter.
The helper waits for the webContents 'focus' event before requesting
pointer lock (#54529). In the parallel phase another spec's window can
hold focus, so the event never arrives and the first attempt times out
on macOS. Tag the block 'serial', like the clipboard and paste blocks
that use the same focus wait.
Claude-Session: https://claude.ai/code/session_011wzReGh8dFocAi8ujeiTsA
Co-authored-by: Claude <noreply@anthropic.com>
The `iframe using HTML fullscreen API while window is OS-fullscreened`
block in chromium.spec.ts and the macOS `fullscreen state` block in
api-browser-window.spec.ts move windows in and out of OS fullscreen.
Under the parallel runner two of these transitions can overlap on
macOS and one never finishes, timing out the test. Tag both blocks
serial.
Claude-Session: https://claude.ai/code/session_01XUFN2KBqhJMviaCibjxNUU
Co-authored-by: Claude <noreply@anthropic.com>
The previous fix waited for the edited form state after navigating away,
where it can only arrive via the old frame's unload-time update. The
browser only waits briefly for that frame to unload, so a slow hidden
renderer could still miss it. Wait for the renderer's delayed state sync
while the form page is still current instead.
Claude-Session: https://claude.ai/code/session_01VEsRtPpi9c1f38o3GaZskj
Co-authored-by: Claude <noreply@anthropic.com>
* chore: bump chromium in DEPS to 156.0.8078.0
* chore: update patches
* 8383239: Introduce a new FindInPage domain (with commands) in DevTools
Upstream moved find request id allocation into FindRequestManager and
now delivers the id through a synchronous callback on WebContents::Find.
Capture that id in FindInPage instead of maintaining Electron's own
counter, so the value returned from findInPage matches the requestId
reported by found-in-page.
Ref: https://chromium-review.googlesource.com/c/chromium/src/+/8383239
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* chore: bump chromium in DEPS to 156.0.8078.3
---------
Co-authored-by: electron-roller[bot] <84116207+electron-roller[bot]@users.noreply.github.com>
Co-authored-by: electron-claude[bot] <279139701+electron-claude[bot]@users.noreply.github.com>
Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
Adds the hold-for-review block to .github/faraday.yml so that a pull request carrying the hold-for-review label is held for 24 business hours (Pacific time) before faraday lets it merge; pull requests carrying fast-track are exempt. The gate is implemented in electron/faraday#24.
Claude-Session: https://claude.ai/code/session_01DpVCp5zarjEPP2s4MQwLXo
Co-authored-by: Claude <noreply@anthropic.com>
With DCHECKs off, SEQUENCE_CHECKER expands to nothing, leaving QueueState
trivially destructible and tripping base::NoDestructor's static_assert.
Give it a user-provided destructor so it is non-trivial in every config.
Claude-Session: https://claude.ai/code/session_01FsSQW86CrHuBNQNRMyPCex
Co-authored-by: Claude <noreply@anthropic.com>
`printToPDF() with custom page sizes` printed 11 page sizes and called
readPDF() on each one. Every readPDF() call starts a full Electron
process to run pdf.js. On macOS x64 CI, with the parallel vitest
workers, that is about 2-5s per call, so the loop often went over the
30s test timeout.
Add readPDFs(), which parses several PDFs in one pdf-reader process.
The test now prints every size first and then parses them all with a
single launch. readPDF() is now a wrapper around readPDFs().
Claude-Session: https://claude.ai/code/session_01TVWNFK7iBS3en5muZhanuM
Co-authored-by: Claude <noreply@anthropic.com>
Clear the retained view and delegate pointers before resetting their owning widget so neither raw_ptr outlives its pointee during CloseDevTools.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
content rejects requestPointerLock() with WrongDocumentError, without
ever consulting the permission request handler, when the widget does not
have focus. On macOS webContents.focus() takes effect asynchronously, so
the request could race ahead of focus and the helper found no recorded
permission request. Wait for the focus event first, and assert the
request was rejected by the handler (SecurityError).
Claude-Session: https://claude.ai/code/session_011wzReGh8dFocAi8ujeiTsA
Co-authored-by: Claude <noreply@anthropic.com>
On a cold launch the framework and its resources are paged in with
thousands of small reads that stall the main thread and child processes.
Read them sequentially on a background thread at the start of the browser
process instead, so those faults hit the page cache.
Skipped when the framework is already resident or memory is short, reads
only the running architecture's slice of a universal binary, and runs at
utility disk priority.
Release cached strings and isolate references in OnBeforeDispose rather than after the isolate has been freed. Add a subprocess regression covering clean shutdown after nativeImage.getSize populates the cache.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Keep a stack-local native pointer and clear the raw_ptr member before Remove() synchronously deletes the native item. Preserve observer removal and download cancellation behavior.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* refactor: add a native peer helper for cppgc wrappers
cppgc wrapper destructors run during sweeping, where they must not touch
other GC objects, run JavaScript, or tear down native registrations.
Debugger, Notification and WebContents each hand rolled an off-heap peer
for this.
Add NativePeer<Wrapper>, which owns native registrations, resources, and
independent V8 roots for a wrapper. The wrapper's deleter only queues the
peer. Queued peers are released and deleted from a posted task. At
shutdown they are released while V8 can still run and deleted after the
isolate is disposed, so peer teardown never runs inside a cppgc finalizer
and nothing leaks.
* chore: apply review feedback
Co-authored-by: Samuel Attard <sam@electronjs.org>
* chore: apply review feedback
Co-authored-by: Samuel Attard <sam@electronjs.org>
---------
Co-authored-by: Samuel Attard <sam@electronjs.org>
* feat: add protocol.registerSource()
A protocol.handle() handler runs on the main thread, so requests to an
app's own scheme wait whenever the main process is busy there, most
visibly at startup when the first window's HTML, scripts and styles are
served by that handler. For the common case of serving bundled files
there is nothing for JavaScript to decide, so let the app declare it:
protocol.registerSource('app', {
routes: [
{ match: { host: 'bundle', path: '/assets/' },
source: { type: 'directory', root: assetsDir } },
{ match: { host: 'bundle' },
source: { type: 'directory', root: distDir } }
]
})
The routes are compiled into an immutable ProtocolSource held by the
session's ProtocolRegistry. The URLLoaderFactory the registry hands out
for the scheme (to renderers for subresources, to navigations, and to
net.fetch through ProtocolRegistry::CreateRegisteredFactory) is bound on
the IO thread; it picks the most specific route (a host match over a
wildcard, then the longest path prefix), resolves the rest of the path
inside that route's root, refusing anything that would leave it, and
hands the file to AsarURLLoader, which reads it on a blocking sequence
the way file: URLs are read, asar archives included, with Content-Type
from the extension and any headers the route adds. AsarURLLoader reads
plain files itself for this (read_plain_files) rather than delegating to
Chromium's file loader, whose Last-Modified formatting costs more than
the read for small files. A scheme has either a handler or a source;
unhandle() removes either and isProtocolHandled() reports both.
Linux x64, page with 60 stylesheets, median of 3 warm loads:
protocol.handle on the main thread 22 ms idle / 120 ms with the main
process busy for 100 ms after navigation; registerSource 13 ms / 14 ms.
Renderer fetch() round trip 0.33 -> 0.20 ms; browser-process CPU per
request 234 -> 200 us with no main-thread time at all.
* test: protocol.registerSource
* fix: address review of protocol.registerSource
- HEAD requests get the response head with Content-Type/Content-Length
and an empty body, without opening or reading the file.
- A satisfiable Range is answered 206 with Content-Range and
Content-Length; an unsatisfiable one 416 with `bytes */size`.
- Route roots are canonicalized at registration and each requested file
is resolved (symlinks included) before it is opened; a file that is not
under the root is not served.
- Plain-file sizes no longer pass through Archive::FileInfo's 32-bit
size, so files over 4 GiB are served whole.
- registerSource rejects the full set of built-in schemes
(ProtocolRegistry::IsBuiltinScheme), not just the legacy list.
- Reduce a few variable scopes, drop Route's out-of-line special members.
* fix: address second review of protocol.registerSource
* chore: oxfmt
* docs: mark protocol.registerSource() and getSource() as experimental
* fix: tighten registerSource() route validation and root containment
* docs: note that loader-computed headers override route headers
vitest starts stopping a finished file's worker without waiting for it, so a
worker in the 'serial' project could launch while earlier Electron workers
were still quitting and be handed activation by them. From that state
app.hide() was ignored, and the macOS app.isActive and app.isHidden specs
timed out on every attempt. Serial workers now wait for all earlier workers
to exit, and the specs take activation through a window of their own before
hiding.
Claude-Session: https://claude.ai/code/session_01JBP7gbUymggpz1TCjF51Q1
Co-authored-by: Claude <noreply@anthropic.com>
toPNG(), toJPEG(), toBitmap(), getBitmap() and getNativeHandle() called
ToLocalChecked() on the Buffer they created. Node.js throws and returns an
empty handle when the current context has no Node.js environment, as in
sandboxed and service worker preload scripts, so the renderer aborted.
Return the empty handle and let the pending exception reach the caller.
toBitmap() now allocates its Buffer before reading pixels, so it throws
before doing the work and a failed allocation throws as well.
* fix: apply setContentProtection() in Windows remote sessions again
Chromium stopped excluding windows from capture in remote sessions so that
its own Picture-in-Picture windows stay visible to the remote user
(https://chromium-review.googlesource.com/c/chromium/src/+/7918332). The
same code path backs setContentProtection(), so since Electron 44 the call
has silently done nothing over Remote Desktop while isContentProtected()
kept returning true. Enable the feature that lifts the restriction by
default, and document the effect on remote users and how to opt out.
* docs: note when setContentProtection() takes effect on Windows
SetWindowDisplayAffinity is applied by the next DWM composition. Measured on
Windows 11 24H2, the first frame without the window was presented 9-42ms after
the call, and a capture started within about 11ms could still contain it.
The XShape request that setIgnoreMouseEvents() issues on X11 stayed in the
client-side output buffer until the UI thread next returned to its message
loop, so the window kept receiving (or kept ignoring) mouse events for as
long as the caller stayed busy. Round-trip to the server after updating the
region. A flush alone only writes the request to the socket; the server
gives no ordering guarantee between clients, so only a reply shows that the
shape is in place before another client's next request is processed.
* fix: let sandboxed processes read per-user install directories with stray AppContainer ACEs on Windows
Sandboxed children run with a restricted token, and Windows evaluates a
restricted token against a DACL that contains any AppContainer package
SID as if it were an AppContainer: only an ALL APPLICATION PACKAGES (or
ALL RESTRICTED APPLICATION PACKAGES) entry can grant access. Per-user
install locations under %LOCALAPPDATA% inherit package ACEs left by
other software and carry neither, so every sandboxed child was denied
its own install directory, died opening icudtl.dat, and the app exited
with "GPU process isn't usable". Program Files installs are unaffected
because they inherit ALL APPLICATION PACKAGES read access.
Probe the install directory with the sandbox's initial token before the
first child is launched and, when the probe is denied, add an inheritable
read/execute ACE for ALL APPLICATION PACKAGES, the same access Program
Files grants by default.
* fix: check sandbox access to the install dir with AccessCheck instead of impersonating
Same probe, but ask the kernel with AccessCheck() against the restricted
token and the file's security descriptor rather than putting the token on
the browser's main thread.
* fix: abort with a descriptive error instead of granting access at runtime
Leave the ACL to installers: check whether the sandbox token can read
the install directory and, if not, stop startup with a message that names
the directory and the icacls command that fixes it.
The test read the restored input value once on dom-ready and then polled
that constant, so any early read turned into a guaranteed 10s timeout.
The saved PageState could also be snapshotted before the old
cross-process form page sent its final state on unload, leaving the
entry without the edited value.
Wait until the saved entry's PageState actually contains the typed value,
then await restore() and assert the input value directly.
Claude-Session: https://claude.ai/code/session_01VEsRtPpi9c1f38o3GaZskj
Co-authored-by: Claude <noreply@anthropic.com>
chrome.tabs.reload() resolves after the reload has started, so the
reply to the 'reload' message is addressed to the document being
replaced. When the new document commits first the reply is dropped,
console-message never fires and the test times out.
Keep the reload result in the service worker, wait for did-finish-load,
then ask the reloaded page for it with a new getReloadStatus message.
Claude-Session: https://claude.ai/code/session_01KgNfjEYpFmXyDvfN11dqJM
Co-authored-by: Claude <noreply@anthropic.com>
When a BrowserWindow was reactivated, the views focus manager restored
focus to the view the user last clicked into, and BrowserWindow's focus
handler then moved it to the window's own webContents unconditionally. A
child WebContentsView therefore lost focus on every Alt+Tab round trip on
Windows and Linux. Leave focus alone when another view in the window
already holds it.
While alert(), confirm() or a beforeunload prompt blocks the renderer,
Chromium ignores focus gains on the page's view. Electron shows these as
native dialogs owned by the window, and closing one hands activation back
to the window before the dialog result is delivered, so the view ended up
focused in aura but blurred in Blink: no caret, and typed characters were
dropped until the window was deactivated and activated again. After the
dialog result unblocks the renderer, replay the focus when the two sides
disagree.
On Linux, disabling a window (setEnabled(false), or opening a modal child)
only took effect under X11; under Wayland the window kept receiving input
and isEnabled() always returned true.
Replace the X11-only EventDisabler rewriter with the window tree host's
DisableEventListening(), which blocks event dispatch the same way on both
X11 and Wayland, and run the disabling specs on Wayland too.
HostZoomMap keys zoom levels for URLs without a host by their full spec,
including the fragment, so on a file: page a location.hash change moved
the page to a new key: getZoomLevel() dropped to the default while the
page kept its zoom, and the next zoom in/out was computed from the
default. Carry the upstream fix
(https://chromium-review.googlesource.com/c/chromium/src/+/8467669),
which strips the fragment from the keying URL.
setVisualZoomLevelLimits() only reached the current renderer, and the
cached WebPreferences that every new render view receives carry the
default 1/1 page scale limits, so the limits were lost on the next
navigation. For <webview> guests they never applied at all because
pinch-zoom is handled by the embedder's compositor. Store the limits in
WebContentsPreferences, recompute WebPreferences when they change, and
forward them to the embedder for guests.
