* fix: run toast creation on background thread
notes: attempts to fix app freeze when triggering notifications and the COM server in WindowsShellExperienceHost hangs
Co-authored-by: Jan Hannemann <jan.hannemann@outlook.com>
* fix: comments
Co-authored-by: Jan Hannemann <jan.hannemann@outlook.com>
---------
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Jan Hannemann <jan.hannemann@outlook.com>
This should fix the oom errors
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: John Kleinschmidt <jkleinsc@electronjs.org>
chore: bump chromium to 144.0.7527.0 40-x-y
* chore: bump chromium in DEPS to 144.0.7527.0
* 7106405: [video pip] Fix gesture handling issues
https://chromium-review.googlesource.com/c/chromium/src/+/7106405
* 7130938: Reland "Remove some dependencies from the custom_handlers component"
https://chromium-review.googlesource.com/c/chromium/src/+/7130938
* 7139361: Rename PluginService's GetPlugins methods
https://chromium-review.googlesource.com/c/chromium/src/+/7139361
* chore: fixup patch indices
* test: fix macos webgl test | 7128438: Reland "Flip SwiftShader deprecation to launched." | https://chromium-review.googlesource.com/c/chromium/src/+/7128438
* test: update webgl test to skip on fallback adapters
* Fixup spec runner to properly fail on linux when tests fail
* test: fixup dbus tests
* test: convert shared-texture-spec from old done callback to async
Fixes Error: done() called multiple times in test <sharedTexture module import shared texture produced by osr successfully imported and rendered with subtle api> of file /__w/electron/electron/src/electron/spec/api-shared-texture-spec.ts
* test: fixup shared texture spec
* Revert "test: fixup dbus tests"
This reverts commit 3e2e720003.
* test: fixup dbus tests
* test: disable context menu spellcheck tests on linux
https://github.com/electron/electron/pull/48657 broke those tests
* disable sharedTexture tests on platforms other than macOS arm64
They were not working on other platforms previously but now they error out.
Also removed extraneous debugging.
* fix: use github.sha for yarn cache key to avoid hashFiles() composite action bug
* Use --immutable-cache to allow native module builds
* fix: wait for devtools blur event in focus test to avoid race condition
* fix: wait for devtools blur event in focus test to avoid race condition
* fix allow native module builds in spec workspace
* test:rebuild native modules
* Revert "fix allow native module builds in spec workspace"
This reverts commit ffda3be98c.
* Revert "Use --immutable-cache to allow native module builds"
This reverts commit 2e6eea4348.
* Revert "fix: use github.sha for yarn cache key to avoid hashFiles() composite action bug"
This reverts commit 33560ba0de.
---------
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: electron-roller[bot] <84116207+electron-roller[bot]@users.noreply.github.com>
In 6399527761 we changed the path strings
that `node_modules.cc` operates on from single-byte to wide strings.
Unfortunately this means that `generic_path()` that the
"fix: ensure TraverseParent bails on resource path exit" patch was
calling was no longer a safe method to call on Windows if the underlying
string has unicode characters in it.
Here we fix it by using `ConvertGenericPathToUTF8` from the Node.js
internal utilities.
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Fedor Indutny <indutny@signal.org>
* docs: explain how to load SF Symbols with `nativeImage`
Co-authored-by: Niklas Wenzel <dev@nikwen.de>
* fix: use single quotes
Co-authored-by: Niklas Wenzel <dev@nikwen.de>
* fix: use single quotes
Co-authored-by: Niklas Wenzel <dev@nikwen.de>
---------
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Niklas Wenzel <dev@nikwen.de>
Make setFocusable only deactivate a window if focusable is false. Do not deactivate a window when setting focusable to true.
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: vulture <isu@vulture.fm>
* docs(timelines): Correct v40.0.0 stable release date
On the Electron Timelines tutorial page (/docs/latest/tutorial/electron-timelines), there is a clear typo in the release schedule for v40.0.0.
The table currently lists the dates as:
* Alpha: 2025-Oct-30
* Beta: 2025-Dec-03
* **Stable: 2025-Oct-28**
This is logically incorrect, as the 'Stable' release date (Oct 28) is listed *before* both the 'Alpha' (Oct 30) and 'Beta' (Dec 03) dates for the same version.
This appears to be a copy-paste error, as the 'Stable' date (2025-Oct-28) is identical to the 'Stable' date for the v39.0.0 release in the preceding row.
This commit updates the 'Stable' date for v40.0.0 to its correct value, ensuring the timeline is accurate and logical.
Co-authored-by: 정승규 <43807509+jsk41755@users.noreply.github.com>
* docs: Update v40.0.0 stable date to 2026-Jan-13 based on Chromium schedule
Co-authored-by: 정승규 <43807509+jsk41755@users.noreply.github.com>
---------
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: 정승규 <43807509+jsk41755@users.noreply.github.com>
trap handlers will be initialized once the user script starts
but before app#ready. Wasm compilation before that phase will
break trap handler registeration due to the check in
v8::internal::wasm::UpdateComputedInformation. For some reason
this issue was only visible in <= 39-x-y when pdf-reader.mjs
was being loaded, maybe some module loading logic changed in >= 40-x-y
which are based on Node.js v24.x. In either case, it is best to
align the loading of wasm module required for the tests in light
of changes to how we are registering the trap handlers for the
main process.
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: deepak1556 <hop2deep@gmail.com>
fix: fix the issue where the parent window remained interactive after the modal window was opened in somecases.
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Bill Shen <15865969+cucbin@users.noreply.github.com>
The install process spawn was not capturing its own signal variable,
causing the error check to incorrectly reference the build signal
instead. This could lead to:
- Install termination by signal going undetected
- False positive errors when build was killed but install succeeded
This commit ensures the install signal is properly captured and
checked, matching the pattern used for the build process.
`bringToFront` DevTools message is sent when breakpoint is triggered
or inspect is called and Chromium upon this message activates DevTools
via `DevToolsUIBindings::Delegate::ActivateWindow`:
```
void DevToolsWindow::ActivateWindow() {
if (life_stage_ != kLoadCompleted)
return;
\#if BUILDFLAG(IS_ANDROID)
NOTIMPLEMENTED();
\#else
if (is_docked_ && GetInspectedBrowserWindow())
main_web_contents_->Focus();
else if (!is_docked_ && browser_ && !browser_->window()->IsActive())
browser_->window()->Activate();
\#endif
}
```
which implements: `DevToolsUIBindings::Delegate::ActivateWindow`.
Electron also implements this interface in:
`electron::InspectableWebContents`. However it was only setting
a zoom level, therefore this commit extends it with activation
of the DevTools.
Only supported for DevTools manged by `electron::InspectableWebContents`.
Closes: #37388
If either `npm_config_electron_use_remote_checksums` or
`electron_use_remote_checksums` are set as environment variables, then
force Electron to verify with remote checksums instead of embedded ones.
Fixes#48594.
* docs: security.md mark 'Enable process sandboxing' as active by default since electron 20
* Adjusted according to feedback
* Updated according to feedback - adjusted sandbox.md
* formatting
* Fixed broken markup
* Implemented docs linting suggestions
* docs: docs/tutorial/sandbox.md - fixed typo
Co-authored-by: Erick Zhao <erick@hotmail.ca>
* docs: web-preferences.md - sandbox: mention default value and relation to nodeIntegration
---------
Co-authored-by: Erick Zhao <erick@hotmail.ca>
* chore: bump nan to 2.23.0
* Fix C++ flags passed to C compiler in NAN spec runner
Passing C++-specific flags to the C compiler caused failures building native test modules.
NAN uprgaded the version of node-gyp it uses, triggering a new codepath with the C compiler that didn't occur before. In that new branch, the C++ flags present in the CFLAGS environment variable we were passing in caused the C compiler to error out:
```
error: invalid argument '-std=c++20' not allowed with 'C'
```
The fix is to only pass C++-specific flags to the C++ compiler, and not the C compiler. This is done by separating out the CFLAGS and CXXFLAGS environment variables in our nan-spec-runner.js script.
I'm curious to know more about why each of these flags are necessary, but for now this change restores the previous behavior where native test modules could be built successfully.
* test: use v8 version check instead of node version check (patch)
* Re-enable `methodswithdata-test`
* chore: bump chromium in DEPS to 143.0.7485.0
* chore: update allow_disabling_blink_scheduler_throttling_per_renderview.patch
Move SetSupportsDraggableRegions mojom IPC from chrome/ and extensions/ to blink/ | https://chromium-review.googlesource.com/c/chromium/src/+/7043264
Patch applied manually due to context shear
* Move SetSupportsDraggableRegions mojom IPC from chrome/ and extensions/ to blink/ | https://chromium-review.googlesource.com/c/chromium/src/+/7043264
* chore: e patches all
* chore: check for file existence before setting utime
* chore: stop disabling kWinDelaySpellcheckServiceInit
[cleanup] Remove feature WinDelaySpellcheckServiceInit | https://chromium-review.googlesource.com/c/chromium/src/+/7012087
This flag has been removed upstream. We've used it since c2d7164 (#38248)
to fix a crash originally described in 97b353a (#34993):
> Delaying spell check initialization is causing specs for
> 'custom dictionary word list API' to fail in Electron.
Since we haven't touched this in a few years, and since there's a
clear success criteria (a passing/failing spec), and since the patch
to restore this flag would be pretty large (~750 lines), I'm going
to try just removing the flag from our source to see if the spec
passes or fails.
* Revert "chore: stop disabling kWinDelaySpellcheckServiceInit"
This reverts commit e688880396.
Unfortunately, the crash persists.
* Revert [cleanup] Remove feature WinDelaySpellcheckServiceInit | https://chromium-review.googlesource.com/c/chromium/src/+/7012087
We currently need this feature
* fixup! chore: check for file existence before setting utime
* fixup! Move SetSupportsDraggableRegions mojom IPC from chrome/ and extensions/ to blink/ | https://chromium-review.googlesource.com/c/chromium/src/+/7043264
Address Robo's code review @ 64c7fd21ed
* fixup! fixup! chore: check for file existence before setting utime
fix: oops typo
---------
Co-authored-by: electron-roller[bot] <84116207+electron-roller[bot]@users.noreply.github.com>
Co-authored-by: Charles Kerr <charles@charleskerr.com>
* fix: Enable shader-f16 on Windows
* fix: include dxil.dll and dxcompiler.dll for windows x64 and arm64
* fix: modified to follow the chromium dawn build configuration
* fix: include dxil.dll and dxcompiler.dll for windows x86
* fix: Modified to avoid explicitly specifying dawn_use_built_dxc
We logged a fatal error but didn't exit with code 1 so the publish kept going. This was caught by a sanity check later down the release process but would have been quicker to fail out here.
Also adds some code to maybe workaround the underlying auth error
fix: fix launch crash when null device is disabled on Windows
add node flag node::ProcessInitializationFlags::kNoStdioInitialization
Co-authored-by: yangzuohui <yangzuohui@bytedance.com>
Co-authored-by: yangliu <yangliu.leo@bytedance.com>
* fix: wrong api call
* fix: consistency of the resize state
* fix: edge cases
* chore: add detailed comments
* fix: lint
* chore: only windows
* chore: use transparent
Dynamic ESM import in non-context-isolated preload
Extend `HostImportModuleWithPhaseDynamically`'s routing to support
Node.js import resolution in non-context-isolated preloads through
`v8_host_defined_options` length check. The length of host defined
options is distinct between Blink and Node.js and we can use it to
determine which resolver to use.
* build: update build tools to get proper exit codes from e build
xref: https://github.com/electron/build-tools/pull/759
* build: target zips directly
mksnapshot and chromedriver have issues with siso trying to run a separate build and zip step, so just target the zip target
* build: don't unzip chromedriver and mksnapshot in tests
The contents of these files are not used in testing, so we shouldn't unzip them.
perf: two minor perf refactors in InvokeIpcCallback()
1. Allocate the CallbackScope on the stack instead of the heap
2. Skip a redundant call to node::Environment::GetCurrent()
* docs: mention that webUtils should be used via preload script
* docs: suppress lint errors
* docs: clarify webUtils usage scope
* docs: exclude potentially dangerous alert() in the example code
* docs: minor change
* docs: minor change
* docs: minor change
* docs: minor change
* docs: minor change
* docs: minor change
* docs: minor change
* docs: minor change
* docs: minor change
* docs: minor change
* docs: make linter happy
* docs: apply suggestion
Co-authored-by: Samuel Attard <samuel.r.attard@gmail.com>
* docs: apply suggestion
Co-authored-by: Samuel Attard <samuel.r.attard@gmail.com>
* docs: apply suggestion
Co-authored-by: Samuel Attard <samuel.r.attard@gmail.com>
* docs: minor change
* docs: minor change
* docs: remove preload line
---------
Co-authored-by: Niklas Wenzel <dev@nikwen.de>
Co-authored-by: Samuel Attard <samuel.r.attard@gmail.com>
* refactor: make api::Clipboard::GetClipboardBuffer() private
* refactor: move GetClipboadBuffer() into anonymous namespace
* refactor: use gin::Arguments in StopRecording()
* refactor: use gin::Arguments in ImageView::New()
* refactor: use gin::Arguments in AppendSwitch()
* refactor: use gin::Arguments WebContentsView::New()
* refactor: make gin::Arguments arg const in WrappableBase::InitWithArgs()
This makes explicit that we are using it for wrapper + isolate, not the args values
* refactor: remove gin_helper::Arguments arg from ExposeAPI()
refactor: remove gin_helper::Arguments arg from ExposeAPIInWorld()
* refactor: remove gin_helper::Arguments arg from ElectronBindings::GetSystemMemoryInfo()
* refactor: remove gin_helper::Arguments arg from preload_utils::GetBinding()
* refactor: use gin::Arguments in OpenExternal()
* refactor: use gin::Arguments in ExecuteInWorld()
* refactor: use gin::Arguments in ExecuteJavaScript()
* refactor: use gin::Arguments in InvokeNew()
* refactor: use gin::Arguments in ExecuteJavaScriptInIsolatedWorld()
* refactor: remove unused GetNextArgument() marshaller for gin_helper::Arguments
* refactor: remove unused #include gin_helper/arguments.h
* chore: remove unused gin_helper::Arguments
* fixup! refactor: use gin::Arguments in ExecuteJavaScriptInIsolatedWorld()
Xref: https://github.com/electron/electron/pull/48447
We overriden the `GetPackageJSON` in Node.js to let us read files
straight from the ASAR file instead of disk. The override works by
providing a JS method with the limitation that it should not throw a
runtime error. However, this invariant was accidentally violated by
`asar.splitPath` that sometimes contrary to its' TypeScript definition
returned `false`.
fix: macOS stop overriding private cornerMask API to fix WindowServer GPU load spike
Electron fetched a custom `_cornerMask` for `ElectronNSWindow` to smooth
vibrancy corners. On macOS 15 (Tahoe) that private hook forces the window
shadow to be rendered from a fully transparent surface, causing the
WindowServer GPU load regression. Remove the `cornerMask` property and
the `_cornerMask` override so we stay on Apple’s default shadow path.
* refactor: make api::Menu inherit from gin::Wrappable*
* refactor: make api::Menu::kWrapperInfo const
* refactor: use three-arg version of GetConstructor in Menu
refactor: undo branch changes to two-arg version of GetConstructor
* fixup! refactor: make api::Menu inherit from gin::Wrappable*
fix: return type of Menu::New
* fixup! refactor: make api::Menu inherit from gin::Wrappable*
make MenuMac's constructor public so that cppgc can use it
* refactor: Pinnable -> SelfKeepAlive
* refactor: use gin::Arguments::ThrowTypeError() in AutoUpdater::SetFeedURL()
* refactor: use gin::Arguments::ThrowTypeError() in Browser::Focus()
* refactor: use gin::Arguments::ThrowTypeError() in SystemPreferences::SetUserDefault()
* refactor: use gin::Arguments::ThrowTypeError() in UtilityProcessWrapper::Create()
* refactor: use gin::Arguments::ThrowTypeError() in UtilityProcessWrapper::PostMessage()
* refactor: use gin::Arguments::ThrowTypeError() in ElectronBundleMover::ShouldContinueMove()
* refactor: use gin::Arguments::ThrowTypeError() in OnClientCertificateSelected()
* refactor: use gin::Arguments::ThrowTypeError() in Session::ClearData()
* refactor: use gin::Arguments::ThrowTypeError() in ElectronBrowserContext::DisplayMediaDeviceChosen()
* refactor: use gin::Arguments::ThrowTypeError() in WebContents::ReplaceMisspelling()
* refactor: use gin::Arguments::ThrowTypeError() in WebContents::Print()
* chore: iwyu shell/common/gin_helper/error_thrower.h
* test: rerun failed tests individually
* ci: use screencapture-nag-remover
Needed to bypass the popup message "bash" is requesting to bypass the system private window picker and directly access your screen and audio.
* Revert "chore: test with 1st quadrant of the window"
No longer needed because of the addition of the
screencapture-nag-remover script.
This reverts commit f4a7e04c0b.
* test: fixup navigationHistory flake
* rerun test up to 3 times
* refactor: make api::Clipboard::GetClipboardBuffer() private
* refactor: move GetClipboadBuffer() into anonymous namespace
* refactor: use gin::Arguments in BaseWindow::MoveAbove()
refactor: use gin::Arguments in BaseWindow::SetAlwaysOnTop()
refactor: use gin::Arguments in BaseWindow::SetIgnoreMouseEvent()
* refactor: use gin::Arguments in BaseWindow::SetProgresBar()
* refactor: use gin::Arguments in BaseWindow::SetVisibleOnAllWorkspaces()
* refactor: use gin::Arguments in BaseWindow::SetVibrancy()
* refactor: use gin::Arguments in BaseWindow::SetAspectRatio()
* refactor: use gin::Arguments in BaseWindow::PreviewFile()
* refactor: use gin::Arguments in BaseWindow::SetThumbarButtons()
* refactor: use gin::Arguments in BaseWindow::SetBounds()
* refactor: use gin::Arguments in BaseWindow::SetContentBounds()
* refactor: use gin::Arguments in BaseWindow::SetSize()
* refactor: use gin::Arguments in BaseWindow::SetContentSize()
* refactor: use gin::Arguments in BaseWindow::SetSheetOffset()
* refactor: use gin::Arguments in BaseWindow::SetPosition()
* refactor: use gin::Arguments in BaseWindow::AddTabbedWindow()
* refactor: use gin::Arguments in BaseWindow::SetParentWindow()
* refactor: use gin::Arguments in BaseWindow::BaseWindow()
* refactor: use gin::Arguments in BaseWindow::SetAccentColor()
* refactor: use gin::Arguments in BaseWindow::SetTitleBarOverlay()
* refactor: narrow App:SetJumpList() arg from gin::Arguments* to v8::Isolate*
* refactor: narrow WebContents::AddWorkSpace() arg from gin::Arguments* to v8::Isolate*
* refactor: narrow ShowMessageBox() arg from gin::Arguments* to v8::Isolate*
* refactor: narrow ShowOpenDialog() arg from gin::Arguments* to v8::Isolate*
* refactor: remove unused gin::Arguments* arg from OverrideGlobalPropertyFromIsolatedWorld()
* refactor: narrow WebContents::StartDrag() arg from gin::Arguments* to v8::Isolate*
* refactor: narrow NetLog::StopLogging() arg from gin::Arguments* to v8::Isolate*
* refactor: narrow Protocol::IsProtocolHandled() arg from gin::Arguments* to v8::Isolate*
* refactor: remove unused isolate arg from Debugger ctor
* refactor: make Debugger ctor, dtor public
needed for cppgc::MakeGarbageCollected()
This is what upstream does, e.g. https://chromium-review.googlesource.com/c/chromium/src/+/6722236
* fixup! refactor: remove unused isolate arg from Debugger ctor
mark Debugger ctor as explicit
* refactor: in EventEmitterMixin, handle both old and new WrapperInfo types
* refactor: make electron::api::Debugger inherit from gin::Wrappable
* refactor: add api::Debugger::GetTypeName()
* refactor: add api::Debugger::GetClassName()
Electron embeds Chromium (rendering) and Node.js (backend) to enable desktop apps with web technologies. The parent directory (`../`) is the Chromium source tree.
### Process Model
Electron has two primary process types, mirroring Chromium:
- **Renderer process** (`shell/renderer/` + `lib/renderer/`): Runs web content in BrowserWindows
### Native ↔ JavaScript Bridge
Each API is implemented as a C++/JS pair:
- C++ side: `shell/browser/api/electron_api_{name}.cc/.h` — uses `gin::Wrappable` and `ObjectTemplateBuilder`
- JS side: `lib/browser/api/{name}.ts` — exports the module, registered in `lib/browser/api/module-list.ts`
- Binding: `NODE_LINKED_BINDING_CONTEXT_AWARE(electron_browser_{name}, Initialize)` in C++ and registered in `shell/common/node_bindings.cc`
- Type declaration: `typings/internal-ambient.d.ts` maps `process._linkedBinding('electron_browser_{name}')`
### Patches System
Electron patches upstream dependencies (Chromium, Node.js, V8, etc.) rather than forking them. Patches live in `patches/` organized by target, with `patches/config.json` mapping directories to repos.
This issue has been automatically marked as stale. **If this issue is still affecting you, please leave any comment** (for example, "bump"), and we'll keep it open. If you have any new additional information—in particular, if this is still reproducible in the [latest version of Electron](https://www.electronjs.org/releases/stable) or in the [beta](https://www.electronjs.org/releases/beta)—please include it with your comment!
close-issue-message:>
This issue has been closed due to inactivity, and will not be monitored. If this is a bug and you can reproduce this issue on a [supported version of Electron](https://www.electronjs.org/docs/latest/tutorial/electron-timelines#timeline) please open a new issue and include instructions for reproducing the issue.
@@ -8,6 +8,12 @@ The Electron team will send a response indicating the next steps in handling you
Report security bugs in third-party modules to the person or team maintaining the module. You can also report a vulnerability through the [npm contact form](https://www.npmjs.com/support) by selecting "I'm reporting a security vulnerability".
## Escalation
If you do not receive an acknowledgement of your report within 6 business days, or if you cannot find a private security contact for the project, you may escalate to the OpenJS Foundation CNA at `security@lists.openjsf.org`.
If the project acknowledges your report but does not provide any further response or engagement within 14 days, escalation is also appropriate.
## The Electron Security Notification Process
For context on Electron's security notification process, please see the [Notifications](https://github.com/electron/governance/blob/main/wg-security/membership-and-notifications.md#notifications) section of the Security WG's [Membership and Notifications](https://github.com/electron/governance/blob/main/wg-security/membership-and-notifications.md) Governance document.
*`type` string (optional) _macOS_ - Can be `mainAppService`, `agentService`, `daemonService`, or `loginItemService`. Defaults to `mainAppService`. Only available on macOS 13 and up. See [app.setLoginItemSettings](app.md#appsetloginitemsettingssettings-macos-windows) for more information about each type.
*`type` string (optional) _macOS_ - Can be one of `mainAppService`, `agentService`, `daemonService`, or `loginItemService`. Defaults to `mainAppService`. Only available on macOS 13 and up. See [app.setLoginItemSettings](app.md#appsetloginitemsettingssettings-macos-windows) for more information about each type.
*`serviceName` string (optional) _macOS_ - The name of the service. Required if `type` is non-default. Only available on macOS 13 and up.
*`path` string (optional) _Windows_ - The executable path to compare against. Defaults to `process.execPath`.
*`args` string[] (optional) _Windows_ - The command-line arguments to compare against. Defaults to an empty array.
@@ -1332,13 +1329,13 @@ Returns `Object`:
*`wasOpenedAtLogin` boolean _macOS_ - `true` if the app was opened at login automatically.
*`wasOpenedAsHidden` boolean _macOS__Deprecated_ - `true` if the app was opened as a hidden login item. This indicates that the app should not open any windows at startup. This setting is not available on [MAS builds][mas-builds] or on macOS 13 and up.
*`restoreState` boolean _macOS__Deprecated_ - `true` if the app was opened as a login item that should restore the state from the previous session. This indicates that the app should restore the windows that were open the last time the app was closed. This setting is not available on [MAS builds][mas-builds] or on macOS 13 and up.
*`status` string _macOS_ - can be `not-registered`, `enabled`, `requires-approval`, or `not-found`.
*`status` string _macOS_ - can be one of `not-registered`, `enabled`, `requires-approval`, or `not-found`.
*`executableWillLaunchAtLogin` boolean _Windows_ - `true` if app is set to open at login and its run key is not deactivated. This differs from `openAtLogin` as it ignores the `args` option, this property will be true if the given executable would be launched at login with **any** arguments.
*`launchItems` Object[] _Windows_
*`name` string _Windows_ - name value of a registry entry.
*`path` string _Windows_ - The executable to an app that corresponds to a registry entry.
*`args` string[] _Windows_ - the command-line arguments to pass to the executable.
*`scope` string _Windows_ - can be`user` or `machine`. Indicates whether the registry entry is under `HKEY_CURRENT USER` or `HKEY_LOCAL_MACHINE`.
*`scope` string _Windows_ - one of`user` or `machine`. Indicates whether the registry entry is under `HKEY_CURRENT USER` or `HKEY_LOCAL_MACHINE`.
*`enabled` boolean _Windows_ - `true` if the app registry key is startup approved and therefore shows as `enabled` in Task Manager and Windows settings.
@@ -32,19 +32,9 @@ update process. Apps that need to disable ATS can add the
### Windows
On Windows, the `autoUpdater` module automatically selects the appropriate update mechanism
based on how your app is packaged:
* **MSIX packages**: If your app is running as an MSIX package (created with [electron-windows-msix][msix-lib] and detected via [`process.windowsStore`](process.md#processwindowsstore-readonly)),
the module uses the MSIX updater, which supports direct MSIX file links and JSON update feeds.
***Squirrel.Windows**: For apps installed via traditional installers (created with
[electron-winstaller][installer-lib] or [Electron Forge's Squirrel.Windows maker][electron-forge-lib]),
the module uses Squirrel.Windows for updates.
You don't need to configure which updater to use; Electron automatically detects the packaging
format and uses the appropriate one.
#### Squirrel.Windows
On Windows, you have to install your app into a user's machine before you can
use the `autoUpdater`, so it is recommended that you use
[electron-winstaller][installer-lib] or [Electron Forge's Squirrel.Windows maker][electron-forge-lib] to generate a Windows installer.
Apps built with Squirrel.Windows will trigger [custom launch events](https://github.com/Squirrel/Squirrel.Windows/blob/51f5e2cb01add79280a53d51e8d0cfa20f8c9f9f/docs/using/custom-squirrel-events-non-cs.md#application-startup-commands)
that must be handled by your Electron application to ensure proper setup and teardown.
@@ -65,14 +55,6 @@ The installer generated with Squirrel.Windows will create a shortcut icon with a
same ID for your app with `app.setAppUserModelId` API, otherwise Windows will
not be able to pin your app properly in task bar.
#### MSIX Packages
When your app is packaged as an MSIX, the `autoUpdater` module provides additional
functionality:
* Use the `allowAnyVersion` option in `setFeedURL()` to allow updates to older versions (downgrades)
* Support for direct MSIX file links or JSON update feeds (similar to Squirrel.Mac format)
## Events
The `autoUpdater` object emits the following events:
@@ -110,7 +92,7 @@ Returns:
Emitted when an update has been downloaded.
With Squirrel.Windows only `releaseName` is available.
On Windows only `releaseName` is available.
> [!NOTE]
> It is not strictly necessary to handle this event. A successfully
@@ -129,12 +111,10 @@ The `autoUpdater` object has the following methods:
### `autoUpdater.setFeedURL(options)`
*`options` Object
*`url` string - The update server URL. For _Windows_ MSIX, this can be either a direct link to an MSIX file (e.g., `https://example.com/update.msix`) or a JSON endpoint that returns update information (see the [Squirrel.Mac][squirrel-mac] README for more information).
@@ -760,9 +756,6 @@ Returns [`Rectangle`](structures/rectangle.md) - The `bounds` of the window as `
> [!NOTE]
> On macOS, the y-coordinate value returned will be at minimum the [Tray](tray.md) height. For example, calling `win.setBounds({ x: 25, y: 20, width: 800, height: 600 })` with a tray height of 38 means that `win.getBounds()` will return `{ x: 25, y: 38, width: 800, height: 600 }`.
> [!NOTE]
> On Wayland, this method will return `{ x: 0, y: 0, ... }` as introspecting or programmatically changing the global window coordinates is prohibited.
#### `win.getBackgroundColor()`
Returns `string` - Gets the background color of the window in Hex (`#RRGGBB`) format.
@@ -976,9 +969,6 @@ Moves window to `x` and `y`.
Returns `Integer[]` - Contains the window's current position.
> [!NOTE]
> On Wayland, this method will return `[0, 0]` as introspecting or programmatically changing the global window coordinates is prohibited.
@@ -664,15 +656,10 @@ the [close event](#event-close).
Focuses on the window.
On Wayland (Linux), the desktop environment may show a notification or flash
the app icon if the window or app is not already focused.
#### `win.blur()`
Removes focus from the window.
Not supported on Wayland (Linux).
#### `win.isFocused()`
Returns `boolean` - Whether the window is focused.
@@ -689,8 +676,6 @@ Shows and gives focus to the window.
Shows the window but doesn't focus on it.
Not supported on Wayland (Linux).
#### `win.hide()`
Hides the window.
@@ -839,8 +824,6 @@ Closes the currently open [Quick Look][quick-look] panel.
Resizes and moves the window to the supplied bounds. Any properties that are not supplied will default to their current values.
On Wayland (Linux), has the same limitations as `setSize` and `setPosition`.
```js
const { BrowserWindow } = require('electron')
@@ -866,9 +849,6 @@ Returns [`Rectangle`](structures/rectangle.md) - The `bounds` of the window as `
> [!NOTE]
> On macOS, the y-coordinate value returned will be at minimum the [Tray](tray.md) height. For example, calling `win.setBounds({ x: 25, y: 20, width: 800, height: 600 })` with a tray height of 38 means that `win.getBounds()` will return `{ x: 25, y: 38, width: 800, height: 600 }`.
> [!NOTE]
> On Wayland, this method will return `{ x: 0, y: 0, ... }` as introspecting or programmatically changing the global window coordinates is prohibited.
#### `win.getBackgroundColor()`
Returns `string` - Gets the background color of the window in Hex (`#RRGGBB`) format.
@@ -886,8 +866,6 @@ See [Setting `backgroundColor`](#setting-the-backgroundcolor-property).
Resizes and moves the window's client area (e.g. the web page) to
the supplied bounds.
On Wayland (Linux), has the same limitations as `setContentSize` and `setPosition`.
#### `win.getContentBounds()`
Returns [`Rectangle`](structures/rectangle.md) - The `bounds` of the window's client area as `Object`.
@@ -917,8 +895,6 @@ Returns `boolean` - whether the window is enabled.
Resizes the window to `width` and `height`. If `width` or `height` are below any set minimum size constraints the window will snap to its minimum size.
On Wayland (Linux), may not work as some window managers restrict programmatic window resizing.
#### `win.getSize()`
Returns `Integer[]` - Contains the window's width and height.
@@ -931,8 +907,6 @@ Returns `Integer[]` - Contains the window's width and height.
Resizes the window's client area (e.g. the web page) to `width` and `height`.
On Wayland (Linux), may not work as some window managers restrict programmatic window resizing.
#### `win.getContentSize()`
Returns `Integer[]` - Contains the window's client area's width and height.
@@ -1070,16 +1044,12 @@ this method throws an error.
#### `win.moveTop()`
Moves window to top(z-order) regardless of focus.
Not supported on Wayland (Linux).
Moves window to top(z-order) regardless of focus
#### `win.center()`
Moves window to the center of the screen.
Not supported on Wayland (Linux).
#### `win.setPosition(x, y[, animate])`
* `x` Integer
@@ -1088,15 +1058,10 @@ Not supported on Wayland (Linux).
Moves window to `x` and `y`.
Not supported on Wayland (Linux).
#### `win.getPosition()`
Returns `Integer[]` - Contains the window's current position.
> [!NOTE]
> On Wayland, this method will return `[0, 0]` as introspecting or programmatically changing the global window coordinates is prohibited.
@@ -193,6 +193,11 @@ Disables the Chromium [sandbox](https://www.chromium.org/developers/design-docum
Forces renderer process and Chromium helper processes to run un-sandboxed.
Should only be used for testing.
### --no-stdio-init
Disable stdio initialization during node initialization.
Used to avoid node initialization crash when the nul device is disabled on Windows platform.
### --proxy-bypass-list=`hosts`
Instructs Electron to bypass the proxy server for the given semi-colon-separated
@@ -361,13 +366,6 @@ Keep in mind that standalone switches can sometimes be split into individual fea
Finally, you'll need to ensure that the version of Chromium in Electron matches the version of the browser you're using to cross-reference the switches.
### Chromium features relevant to Electron apps
* `AlwaysLogLOAFURL`: enables script attribution for
@@ -94,45 +94,18 @@ The `desktopCapturer` module has the following methods:
Returns `Promise<DesktopCapturerSource[]>` - Resolves with an array of [`DesktopCapturerSource`](structures/desktop-capturer-source.md) objects, each `DesktopCapturerSource` represents a screen or an individual window that can be captured.
> [!NOTE]
> * Capturing audio requires `NSAudioCaptureUsageDescription` Info.plist key on macOS 14.2 Sonoma and higher - [read more](#macos-versions-142-or-higher).
> * Capturing the screen contents requires user consent on macOS 10.15 Catalina or higher, which can detected by [`systemPreferences.getMediaAccessStatus`][].
> Capturing the screen contents requires user consent on macOS 10.15 Catalina or higher,
> which can detected by [`systemPreferences.getMediaAccessStatus`][].
`desktopCapturer.getSources(options)` only returns a single source on Linux when using Pipewire.
PipeWire supports a single capture for both screens and windows. If you request the window and screen type, the selected source will be returned as a window capture.
---
`navigator.mediaDevices.getUserMedia` does not work on macOS for audio capture due to a fundamental limitation whereby apps that want to access the system's audio require a [signed kernel extension](https://developer.apple.com/library/archive/documentation/Security/Conceptual/System_Integrity_Protection_Guide/KernelExtensions/KernelExtensions.html). Chromium, and by extension Electron, does not provide this.
### MacOS versions 14.2 or higher
`NSAudioCaptureUsageDescription` Info.plist key must be added in-order for audio to be captured by `desktopCapturer`. If instead you are running electron from another program like a terminal or IDE then that parent program must contain the Info.plist key.
This is in order to facillitate use of Apple's new [CoreAudio Tap API](https://developer.apple.com/documentation/CoreAudio/capturing-system-audio-with-core-audio-taps#Configure-the-sample-code-project) by Chromium.
> [!WARNING]
> Failure of `desktopCapturer` to start an audio stream due to `NSAudioCaptureUsageDescription` permission not present will still create a dead audio stream however no warnings or errors are displayed.
As of electron `v39.0.0-beta.4` Chromium [made Apple's new `CoreAudio Tap API` the default](https://source.chromium.org/chromium/chromium/src/+/ad17e8f8b93d5f34891b06085d373a668918255e) for desktop audio capture. There is no fallback to the older `Screen & System Audio Recording` permissions system even if [CoreAudio Tap API](https://developer.apple.com/documentation/CoreAudio/capturing-system-audio-with-core-audio-taps) stream creation fails.
If you need to continue using `Screen & System Audio Recording` permissions for `desktopCapturer` on macOS versions 14.2 and later, you can apply a chromium feature flag to force use of that older permissions system:
```js
// main.js (right beneath your require/import statments)
`navigator.mediaDevices.getUserMedia` does not work on macOS versions 12.7.6 and prior for audio capture due to a fundamental limitation whereby apps that want to access the system's audio require a [signed kernel extension](https://developer.apple.com/library/archive/documentation/Security/Conceptual/System_Integrity_Protection_Guide/KernelExtensions/KernelExtensions.html). Chromium, and by extension Electron, does not provide this. Only in macOS 13 and onwards does Apple provide APIs to capture desktop audio without the need for a signed kernel extension.
It is possible to circumvent this limitation by capturing system audio with another macOS app like [BlackHole](https://existential.audio/blackhole/) or [Soundflower](https://rogueamoeba.com/freebies/soundflower/) and passing it through a virtual audio input device. This virtual device can then be queried with `navigator.mediaDevices.getUserMedia`.
It is possible to circumvent this limitation by capturing system audio with another macOS app like Soundflower and passing it through a virtual audio input device. This virtual device can then be queried with `navigator.mediaDevices.getUserMedia`.
Notification replied to (com.github.Electron:notification:EAF7B87C-A113-43D7-8E76-F88EC9D73D44)
```
### `ELECTRON_DEBUG_MSIX_UPDATER`
Adds extra logs to MSIX updater operations on Windows to aid in debugging. Extra logging will be displayed when MSIX update operations are initiated, including package updates, package registration, and restart registration. This helps diagnose issues with MSIX package updates and deployments.
Sample output:
```sh
UpdateMsix called with URI: https://example.com/app.msix
> Import shared textures into Electron and converts platform specific handles into [`VideoFrame`](https://developer.mozilla.org/en-US/docs/Web/API/VideoFrame). Supports all Web rendering systems, and can be transferred across Electron processes. Read [here](https://github.com/electron/electron/blob/main/shell/common/api/shared_texture/README.md) for more information.
*`options` Object - Options for importing shared textures.
*`textureInfo` [SharedTextureImportTextureInfo](structures/shared-texture-import-texture-info.md) - The information of the shared texture to import.
*`allReferencesReleased` Function (optional) - Called when all references in all processes are released. You should keep the imported texture valid until this callback is called.
Imports the shared texture from the given options.
> [!NOTE]
> This method is only available in the main process.
Returns `SharedTextureImported` - The imported shared texture.
*`options` Object - Options for sending shared texture.
*`frame` [WebFrameMain](web-frame-main.md) - The target frame to transfer the shared texture to. For `WebContents`, you can pass `webContents.mainFrame`. If you provide a `webFrameMain` that is not a main frame, you'll need to enable `webPreferences.nodeIntegrationInSubFrames` for this, since this feature requires [IPC](https://www.electronjs.org/docs/latest/api/web-frame-main#frameipc-readonly) between main and the frame.
*`importedSharedTexture` [SharedTextureImported](structures/shared-texture-imported.md) - The imported shared texture.
*`...args` any[] - Additional arguments to pass to the renderer process.
Send the imported shared texture to a renderer process. You must register a receiver at renderer process before calling this method. This method has a 1000ms timeout. Ensure the receiver is set and the renderer process is alive before calling this method.
> [!NOTE]
> This method is only available in the main process.
Returns `Promise<void>` - Resolves when the transfer is complete.
*`pixelFormat` string - The pixel format of the texture.
*`bgra` - 32bpp BGRA (byte-order), 1 plane.
*`rgba` - 32bpp RGBA (byte-order), 1 plane.
*`rgbaf16` - Half float RGBA, 1 plane.
*`colorSpace` [ColorSpace](color-space.md) (optional) - The color space of the texture.
*`codedSize` [Size](size.md) - The full dimensions of the shared texture.
*`visibleRect` [Rectangle](rectangle.md) (optional) - A subsection of [0, 0, codedSize.width, codedSize.height]. In common cases, it is the full section area.
*`timestamp` number (optional) - A timestamp in microseconds that will be reflected to `VideoFrame`.
*`handle` [SharedTextureHandle](shared-texture-handle.md) - The shared texture handle.
*`getVideoFrame` Function\<[VideoFrame](https://developer.mozilla.org/en-US/docs/Web/API/VideoFrame)\> - Create a `VideoFrame` that uses the imported shared texture in the current process. You can call `VideoFrame.close()` once you've finished using the object. The underlying resources will wait for GPU finish internally.
*`release` Function - Release the resources. If you transferred and get multiple `SharedTextureImported` objects, you have to `release` every one of them. The resource on the GPU process will be destroyed when the last one is released.
*`callback` Function (optional) - Callback when the GPU command buffer finishes using this shared texture. It provides a precise event to safely release dependent resources. For example, if this object is created by `finishTransferSharedTexture`, you can use this callback to safely release the original one that called `startTransferSharedTexture` in other processes. You can also release the source shared texture that was used to `importSharedTexture` safely.
*`startTransferSharedTexture` Function\<[SharedTextureTransfer](shared-texture-transfer.md)\> - Create a `SharedTextureTransfer` that can be serialized and transferred to other processes.
*`getFrameCreationSyncToken` Function\<[SharedTextureSyncToken](shared-texture-sync-token.md)\> - This method is for advanced users. If used, it is typically called after `finishTransferSharedTexture`, and should be passed to the object which was called `startTransferSharedTexture` to prevent the source object release the underlying resource before the target object actually acquire the reference at gpu process asyncly.
*`setReleaseSyncToken` Function - This method is for advanced users. If used, this object's underlying resource will not be released until the set sync token is fulfilled at gpu process. By using sync tokens, users are not required to use release callbacks for lifetime management.
*`syncToken` [SharedTextureSyncToken](shared-texture-sync-token.md) - The sync token to set.
*`textureId` string - The unique identifier of the imported shared texture.
*`getVideoFrame` Function\<[VideoFrame](https://developer.mozilla.org/en-US/docs/Web/API/VideoFrame)\> - Create a `VideoFrame` that uses the imported shared texture in the current process. You can call `VideoFrame.close()` once you've finished using the object. The underlying resources will wait for GPU finish internally.
*`release` Function - Release this object's reference of the imported shared texture. The underlying resource will be alive until every reference is released.
*`subtle` [SharedTextureImportedSubtle](shared-texture-imported-subtle.md) - Provides subtle APIs to interact with the imported shared texture for advanced users.
*`importSharedTexture` Function\<[SharedTextureImportedSubtle](shared-texture-imported-subtle.md)\> - Imports the shared texture from the given options. Returns the imported shared texture.
*`textureInfo` [SharedTextureImportTextureInfo](shared-texture-import-texture-info.md) - The information of shared texture to import.
*`finishTransferSharedTexture` Function\<[SharedTextureImportedSubtle](shared-texture-imported-subtle.md)\> - Finishes the transfer of the shared texture and gets the transferred shared texture. Returns the imported shared texture from the transfer object.
*`transfer` [SharedTextureTransfer](shared-texture-transfer.md) - The transfer object of the shared texture.
*`transfer` string _Readonly_ - The opaque transfer data of the shared texture. This can be transferred across Electron processes.
*`syncToken` string _Readonly_ - The opaque sync token data for frame creation.
*`pixelFormat` string _Readonly_ - The pixel format of the transferring texture.
*`codedSize` [Size](size.md) _Readonly_ - The full dimensions of the shared texture.
*`visibleRect` [Rectangle](rectangle.md) _Readonly_ - A subsection of [0, 0, codedSize.width(), codedSize.height()]. In common cases, it is the full section area.
*`timestamp` number _Readonly_ - A timestamp in microseconds that will be reflected to `VideoFrame`.
Use `sharedTexture.subtle.finishTransferSharedTexture` to get [`SharedTextureImportedSubtle`](shared-texture-imported-subtle.md) back.
@@ -12,6 +12,19 @@ This document uses the following convention to categorize breaking changes:
* **Deprecated:** An API was marked as deprecated. The API will continue to function, but will emit a deprecation warning, and will be removed in a future release.
* **Removed:** An API or feature was removed, and is no longer supported by Electron.
## Planned Breaking API Changes (40.0)
### Deprecated: `clipboard` API access from renderer processes
Using the `clipboard` API directly in the renderer process is deprecated.
If you want to call this API from a renderer process, place the API call in
your preload script and expose it using the [contextBridge](https://www.electronjs.org/docs/latest/api/context-bridge) API.
### Behavior Changed: MacOS dSYM files now compressed with tar.xz
Debug symbols for MacOS (dSYM) now use xz compression in order to handle larger file sizes. `dsym.zip` files are now
`dsym.tar.xz` files. End users using debug symbols may need to update their zip utilities.
## Planned Breaking API Changes (39.0)
### Deprecated: `--host-rules` command line switch
### Behavior Changed: `NSAudioCaptureUsageDescription` should be included in your app's Info.plist file to use `desktopCapturer` (🍏 macOS ≥14.2)
Per [Chromium update](https://source.chromium.org/chromium/chromium/src/+/ad17e8f8b93d5f34891b06085d373a668918255e) which enables Apple's newer [CoreAudio Tap API](https://developer.apple.com/documentation/CoreAudio/capturing-system-audio-with-core-audio-taps#Configure-the-sample-code-project) by default, you now must have `NSAudioCaptureUsageDescription` defined in your `Info.plist` to use `desktopCapturer`.
Electron's `desktopCapturer` will create a dead audio stream if the new permission is absent however no errors or warnings will occur. This is partially a side-effect of Chromium not falling back to the older `Screen & System Audio Recording` permissions system if the new system fails.
To restore previous behavior:
```js
// main.js (right beneath your require/import statments)
app.commandLine.appendSwitch(
'disable-features',
'MacCatapLoopbackAudioForScreenShare'
)
```
### Behavior Changed: shared texture OSR `paint` event data structure
When using shared texture offscreen rendering feature, the `paint` event now emits a more structured object.
In this next step, we will create our `BrowserWindow` and tell our application how to handle an event in which an external protocol is clicked.
In this next step, we will create our `BrowserWindow` and tell our application how to handle an event in which an external protocol is clicked.
This code will be different in Windows and Linux compared to macOS. This is due to both platforms emitting the `second-instance` event rather than the `open-url` event and Windows requiring additional code in order to open the contents of the protocol link within the same Electron instance. Read more about this [here](../api/app.md#apprequestsingleinstancelockadditionaldata).
This code will be different in Windows and Linux compared to MacOS. This is due to both platforms emitting the `second-instance` event rather than the `open-url` event and Windows requiring additional code in order to open the contents of the protocol link within the same Electron instance. Read more about this [here](../api/app.md#apprequestsingleinstancelockadditionaldata).
#### Windows and Linux code:
@@ -91,7 +91,7 @@ if (!gotTheLock) {
}
```
#### macOS code:
#### MacOS code:
```js @ts-type={createWindow:()=>void}
// This method will be called when Electron has finished
@@ -200,7 +200,7 @@ macOS has a number of platform-specific menu roles available. Many of these map
* `recentDocuments` - The submenu is an "Open Recent" menu.
* `clearRecentDocuments` - Map to the [`clearRecentDocuments`](https://developer.apple.com/documentation/appkit/nsdocumentcontroller/clearrecentdocuments(_:)) action.
* `shareMenu` - The submenu is [share menu](../api/share-menu.md). The `sharingItem` property must also be set to indicate the item to share.
* `shareMenu` - The submenu is [share menu][ShareMenu]. The `sharingItem` property must also be set to indicate the item to share.
> [!IMPORTANT]
> When specifying a `role` on macOS, `label` and `accelerator` are the only
@@ -1339,7 +1339,7 @@ For developers wanting to learn more, you can refer to the [official N-API docum
### Putting `cpp_addon.cc` together
We've now finished the bridge part of our addon - that is, the code that's most concerned with being the bridge between your JavaScript and C++ code (and by contrast, less so actually interacting with the operating system or GTK). After adding all the sections above, your `src/cpp_addon.cc` should look like this:
We've now finished the bridge part our addon - that is, the code that's most concerned with being the bridge between your JavaScript and C++ code (and by contrast, less so actually interacting with the operating system or GTK). After adding all the sections above, your `src/cpp_addon.cc` should look like this:
@@ -4,13 +4,13 @@ This tutorial builds on the [general introduction to Native Code and Electron](.
Specifically, we'll be integrating with two commonly used native Windows libraries:
*`comctl32.lib`, which contains common controls and user interface components. It provides various UI elements like buttons, scrollbars, toolbars, status bars, progress bars, and tree views. As far as GUI development on Windows goes, this library is very low-level and basic - more modern frameworks like WinUI or WPF are more advanced alternatives but require a lot more C++ and Windows version considerations than are useful for this tutorial. This way, we can avoid the many perils of building native interfaces for multiple Windows versions!
*`comctl32.lib`, which contains common controls and user interface components. It provides various UI elements like buttons, scrollbars, toolbars, status bars, progress bars, and tree views. As far as GUI development on Windows goes, this library is very low-level and basic - more modern frameworks like WinUI or WPF are advanced and alternatives but require a lot more C++ and Windows version considerations than are useful for this tutorial. This way, we can avoid the many perils of building native interfaces for multiple Windows versions!
*`shcore.lib`, a library that provides high-DPI awareness functionality and other Shell-related features around managing displays and UI elements.
This tutorial will be most useful to those who already have some familiarity with native C++ GUI development on Windows. You should have experience with basic window classes and procedures, like `WNDCLASSEXW` and `WindowProc` functions. You should also be familiar with the Windows message loop, which is the heart of any native application - our code will be using `GetMessage`, `TranslateMessage`, and `DispatchMessage` to handle messages. Lastly, we'll be using (but not explaining) standard Win32 controls like `WC_EDITW` or `WC_BUTTONW`.
> [!NOTE]
> If you're not familiar with C++ GUI development on Windows, we recommend Microsoft's excellent documentation and guides, particularly for beginners. "[Get Started with Win32 and C++](https://learn.microsoft.com/en-us/windows/win32/learnwin32/learn-to-program-for-windows)" is a great introduction.
> If you're not familiar with C++ GUI development on Windows, we recommend Microsoft's excellent documentation and guides, particular for beginners. "[Get Started with Win32 and C++](https://learn.microsoft.com/en-us/windows/win32/learnwin32/learn-to-program-for-windows)" is a great introduction.
## Requirements
@@ -1333,7 +1333,7 @@ npm run build
## Conclusion
You've now built a complete native Node.js addon for Windows using C++ and the Win32 API. Some of the things we've done here are:
You've now built a complete native Node.js addon for Windows using C++ and the Win32 API. Some of things we've done here are:
1. Creating a native Windows GUI from C++
2. Implementing a Todo list application with Add, Edit, and Delete functionality
@@ -38,7 +38,7 @@ To test your app, use a Windows on Arm device running Windows 10 (version 1903 o
### Node.js/node-gyp
[Node.js v12.9.0 or later is recommended.](https://nodejs.org/en/) If updating to a new version of Node is undesirable, you can instead [update npm's copy of node-gyp manually](https://github.com/nodejs/node-gyp/wiki/Updating-npm's-bundled-node-gyp) to version 5.0.2 or later, which contains the required changes to compile native modules for Arm.
[Node.js v12.9.0 or later is recommended.](https://nodejs.org/en/) If updating to a new version of Node is undesirable, you can instead [update npm's copy of node-gyp manually](https://github.com/nodejs/node-gyp/wiki/Updating-npm's-bundled-node-gyp) to version 5.0.2 or later, which contains the required changes to compile native modules for Arm.
console.error(`The imported shared texture ${wrapper.texture.textureId} is referenced by a destroyed webContent/webFrameMain, this means a imported shared texture in renderer process is not released before the process is exited. Releasing that dangling reference now.`);
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.