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.
gfx::PNGCodec::Decode() returns a null SkBitmap when it fails to decode
the clipboard contents as a PNG. Passing that null bitmap to
gfx::Image::CreateFrom1xBitmap() triggers a crash.
Return an empty gfx::Image instead, matching the existing null-check
pattern in skia_util.cc.
GetDefaultPrinterDPI() creates a blank GtkPrintSettings and reads
its resolution, which returns 0 for uninitialized settings. With
DPI=0, SetPrintableAreaIfValid() computes a zero scale factor,
producing empty page dimensions that fail PrintMsgPrintParamsIsValid().
Fall back to kDefaultPdfDpi (72) when GTK returns 0, matching the
existing Windows fallback pattern when CreateDC fails.
fix: register PrintDialogLinuxFactory on Linux
Chromium 145 refactored Linux print dialog creation to use a factory
pattern instead of directly calling LinuxUi::CreatePrintDialog().
Chrome registers this factory in
ChromeBrowserMainExtraPartsViewsLinux::ToolkitInitialized(), but
Electron did not, causing PrintingContextLinux::EnsurePrintDialog()
to leave print_dialog_ null on every call.
Without a dialog, UseDefaultSettings() and UpdatePrinterSettings()
return success but with empty/unprocessed settings, causing
PrintMsgPrintParamsIsValid() to fail. This broke both window.print()
(no dialog appears) and webContents.print() (callback stuck until
app close with "Invalid printer settings").
* fix: hex-encode Windows notification icon temp filenames
NotificationPresenterWin was using SHA1HashString(origin.spec()) directly
as the basename for the temporary PNG written for toast icons.
SHA1HashString returns raw digest bytes, so the generated filename could
contain invalid path characters on Windows. That caused WriteFile to fail
when saving notification icons, which left toast XML without the expected
icon path.
Hex-encode the digest before appending .png so the temporary filename is
filesystem-safe while keeping deterministic naming for a given origin.
* Update shell/browser/notifications/win/notification_presenter_win.cc
Co-authored-by: Robo <hop2deep@gmail.com>
---------
Co-authored-by: Robo <hop2deep@gmail.com>
- export_gin_v8platform_pageallocator_for_usage_outside_of_the_gin.patch:
gin::V8Platform::GetPageAllocator() is now exported upstream via the
public v8::Platform interface, so we no longer need to patch gin to
expose a custom accessor. Update javascript_environment.cc to use the
upstream API instead.
- fix_getcursorscreenpoint_wrongly_returns_0_0.patch: this fix has
landed upstream in Chromium and is no longer needed as a local patch.
* refactor: SafeV8Function to be backed by cppgc
* spec: focus renderer before attempting paste
* spec: remove listeners to prevent leak on failed tests
* fix: lazily initialize safeStorage async encryptor
The SafeStorage constructor previously registered a browser observer that
called os_crypt_async()->GetInstance() on app-ready. Because ESM named
imports (import { x } from 'electron') eagerly evaluate all electron
module getters, simply importing electron in an ESM entrypoint would
construct SafeStorage and touch the OS keychain on app-ready, even when
safeStorage was never used.
This showed up as a macOS CI hang: the esm-spec import-meta fixture
triggers a keychain access prompt that blocks the test runner until
timeout.
Now the async encryptor is requested lazily on the first call to
encryptStringAsync, decryptStringAsync, or isAsyncEncryptionAvailable.
isAsyncEncryptionAvailable now returns a Promise that resolves once
initialization completes, matching what the docs already stated.
* chore: lint
* fix: add HandleScope in OnOsCryptReady for pending operations
OnOsCryptReady fires asynchronously from a posted task without an active
V8 HandleScope. Previously this was harmless because eager init meant the
pending queues were always empty when it fired. With lazy init, operations
queue up first, then the callback processes them and needs to create V8
handles (Buffer::Copy, Dictionary::CreateEmpty, Promise::Resolve).
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.
* feat: add copyVideoFrameAt and saveVideoFrameAs Method on Webcontent
chore: change the description of savevideoframe api
chore: add the description of the restrictive elements for using the APIs.
move to webframemain
fixed mediaPlayerAction to kSaveVideoFrameAs
Update spec/api-web-frame-main-spec.ts
Co-authored-by: John Kleinschmidt <kleinschmidtorama@gmail.com>
Update spec/api-web-frame-main-spec.ts
Co-authored-by: John Kleinschmidt <kleinschmidtorama@gmail.com>
fixed clipboard tests for video frame copying
fixed test for copying video frame to clipboard. check video loaded before copy video frame in test.
chore: try non-proprietary video format
Revert "chore: try non-proprietary video format"
This reverts commit ef085f88a1af53b6408a7af695cc60b8681398cf.
fix: format video as file url
* test: skip webFrameMain.copyVideoFrameAt on win32 CI due Chromium DCHECK
* 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
* fix: narrow HandleTermination and Shutdown to uint32_t, add tests
* feat: support notification priority on Windows
Add Windows notifications support urgency/priority levels.
This maps the existing `urgency` option (previously Linux-only) to
Windows toast notification priorities:
- 'critical' maps to ToastNotificationPriority_High, which sorts the
notification above default-priority items in Action Center.
- 'normal' and 'low' both map to ToastNotificationPriority_Default.
Note that on Windows, 'critical' priority does not prevent the toast
from being auto-dismissed. Users should additionally set `timeoutType`
to 'never' for that behavior.
* chore: make linter happy
---------
Co-authored-by: Charles Kerr <charles@charleskerr.com>
build: remove macos hittest workaround patch
CL:6574464 changed BridgedContentView::hitTest: to use GetHitTestResult(), which
returns kRootView for any non-null, non-NativeViewHost view — causing
BridgedContentView to absorb all web content mouse events. In BrowserWindow,
content_view_ sits in front of the sibling WebContentsView and covers the full
client area, so it was always found first, breaking all loadURL page interaction.
Fix this by installing a ContentViewTargeterDelegate on content_view_ in
NativeWindowMac::SetContentView that returns nullptr (instead of the view itself)
when no children cover the target point. This makes GetHitTestResult return kOther,
allowing hitTest: to fall through to [super hitTest:] and find
RenderWidgetHostViewCocoa. This also removes the now-unnecessary chromium
partial-revert patch that worked around the same issue.
refactor: replace CHILD_PLUGIN with CHILD_EMBEDDER_FIRST on macOS
Chromium removed upstream support for child plugin processes without
library validation in https://crbug.com/461717105, which we patched
back via feat_restore_macos_child_plugin_process.patch.
Chromium's CHILD_EMBEDDER_FIRST mechanism already provides the right
extensibility point for this: values > CHILD_EMBEDDER_FIRST are reserved
for embedders and resolved via ContentBrowserClient::GetChildProcessSuffix().
Chrome itself uses this pattern for its Alerts helper process.
This commit replaces the Chromium patch with an Electron-native
implementation.
* feat: add custom `id` property to Notification API (macOS only)
* feat: add `groupId` property to Notification API (macOS). Notifications with the same groupId will be visually grouped together in Notification Center
* fix: move validation to construction time, add empty string check, remove setters
* docs: clarify id/group id properties, make instance properties read-only
* test: update tests to reflect read-only properties
* remove painting from linux frame layout
* use chromium csd strategy for frameless windows
* Apply suggestions from code review
Remove unneeded virtual methods
Co-authored-by: Charles Kerr <charles@charleskerr.com>
* removed inline destructors
---------
Co-authored-by: Charles Kerr <charles@charleskerr.com>
* refactor: migrate electron::api::tray to cppgc
* chore: add Tray to wrappable_pointer_tags.h patch
* fixup! refactor: migrate electron::api::tray to cppgc
clear keep_alive_ if error is thrown in constructor
* refactor: make Tray::menu_ a cppgc::Member<Menu>
* fix: prevent traffic light buttons flashing on deminiaturize
When a window with a custom `trafficLightPosition` is minimized and
restored, macOS re-layouts the title bar container during the
deminiaturize animation, causing the traffic light buttons to briefly
appear at their default position before being repositioned.
Fix this by hiding the buttons container in `windowWillMiniaturize` and
restoring them (with a redraw to the correct position) in
`windowDidDeminiaturize`.
* chore: address feedback from review
* fix: continue to run ProxyingURLLoaderFactory for intercepted protocols
* test: webRequest handlers when loading browser windows
* fix: wrap special URL loaders factories with ProxyingURLLoaderFactory
* test: webRequest handlers when using net.fetch
* refactor: remove redundant intercepted protocol handling
AsarURLLoaderFactory is now intercepted by ProxyingURLLoaderFactory, which already handles when the file:// scheme is intercepted.
* fix: check before using saved headers in OnReceiveResponse
* fix: run webRequest handlers when loading file service workers
* test: handlers when loading file service workers
* refactor: add shared CreateURLLoaderFactoryBuilder method
---------
Co-authored-by: John Kleinschmidt <jkleinsc@electronjs.org>
* Feat: support getDevToolsId() on WebContents
* Rename to `getOrCreateDevToolsTargetId`
* build: use spawn instead of spawnSync for build (#49774)
* Fix build
* formatting
---------
Co-authored-by: John Kleinschmidt <jkleinsc@electronjs.org>
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.
* fix: use requesting frame origin instead of top-level URL for permissions
`WebContentsPermissionHelper::RequestPermission` passes
`web_contents_->GetLastCommittedURL()` as the origin to the permission
manager instead of the actual requesting frame's origin. This enables
origin confusion when granting permissions to embedded third-party iframes,
since app permission handlers see the top-level origin instead of the
iframe's. The same pattern exists in the HID, USB, and Serial device
choosers, where grants are keyed to the primary main frame's origin rather
than the requesting frame's.
Fix this by using `requesting_frame->GetLastCommittedOrigin()` in all
affected code paths, renaming `details.requestingUrl` to
`details.requestingOrigin`, and populating it with the serialized
origin only.
* chore: keep requestingUrl name in permission handler details
The previous commit changed the details.requestingUrl field to
details.requestingOrigin in permission request/check handlers. That
field was already populated from the requesting frame's RFH, so the
rename was unnecessary and would break apps that read the existing
property. Revert to requestingUrl to preserve the existing API shape.
The functional changes to use the requesting frame in
WebContentsPermissionHelper and the HID/USB/Serial choosers remain.
---------
Co-authored-by: Samuel Attard <sattard@anthropic.com>
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.
* test: fix flaky mac dock & autofill tests
* fix: add null checks for the parent widget before calling IsVisible()
* test: remove autofill test change (failing on Linux), keep crash fix
* chore: autofill updates from code review
* docs: document that getCursorScreenPoint() needs a Window on Wayland
* feat: add IsWayland() helper
* fix: Wayland crash in GetCursorScreenPoint()
fix: support Screen::GetCursorScreenPoint() on X11
* refactor: replace deprecated NSUserNotifications with User Notifications
Removes deprecated NSUserNotification API, now using User Notifications
It replaces API calls for generating, scheduling, and receiving native
macOS notifications with equivalent API calls from the new framework,
or functionally equivalent implementations.
To preserve the existing Notification module API, special handling was
required in certain cases:
- Dynamically declared notification actions
Typically, notification actions should be declared at app launch time
when using the User Notifications framework. However, this isn’t
compatible with Electron’s architecture. Instead, we dynamically
declare new notifications actions when necessary and carefully manage
the existing actions registered at runtime.
- Localizations for ‘Reply’ and ‘Show’ labels
New translation files are added and processed through GRIT to add
localizations for “Reply” and “Show” button labels which were
initially supplied by the NSUserNotification framework.
* Use NotificationImageRetainer pattern from //chrome
* build: fix lint
* build: update config to handle --translate-gender for pak files
* test: also sign on arm64
* fix: add error handling for scheduling notification
* docs: add details to breaking changes
* docs: clarify breaking change details
* docs: add details for notifications tutorial and API documentation
---------
Co-authored-by: Keeley Hammond <khammond@slack-corp.com>
PowerMonitor registered OS-level callbacks (HWND UserData and
WTS/suspend notifications on Windows, shutdown handler and lock-screen
observer on macOS) but never cleaned them up in its destructor. The JS
layer also only held the native object in a closure-local variable,
allowing GC to reclaim it while those registrations still referenced
freed memory.
Retain the native PowerMonitor at module level in power-monitor.ts so
it cannot be garbage-collected. Add DestroyPlatformSpecificMonitors()
to properly tear down OS registrations on destruction: on Windows,
unregister WTS and suspend notifications, clear GWLP_USERDATA, and
destroy the HWND; on macOS, remove the emitter from the global
MacLockMonitor and reset the Browser shutdown handler.
Previously, GetProtocolLaunchPath and FormatCommandLineString in
browser_win.cc used naive quoting which could break when paths or
arguments contained backslashes, spaces, or embedded quotes.
Fix by extracting the CommandLineToArgvW-compatible quoting logic from
relauncher_win.cc into a shared utility and use it in both browser_win.cc
and relauncher_win.cc to properly quote the exe path and each argument
individually.
