When widevine was disabled at the build level we never dealt with the callback passed into GetSupportedKeySystems. This was ok until requests became marked pending in https://chromium-review.googlesource.com/c/chromium/src/+/3430502 until the callback was called. This resulted in a promise never resolving / rejecting and certain media websites (E.g. spotify) hanging on load waiting for a signal that would never arrive.
Co-authored-by: Samuel Attard <sattard@salesforce.com>
* fix: performance problem in crashReporter.start() on macOS
This change reduces the duration of crashReporter.start() on Intel macOS
from 622 milliseconds to 257 milliseconds!
Backports https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3641386
posix: Replace DoubleForkAndExec() with ForkAndSpawn()
The DoubleForkAndExec() function was taking over 622 milliseconds to run
on macOS 11 (BigSur) on Intel i5-1038NG7. I did some debugging by adding
some custom traces and found that the fork() syscall is the bottleneck
here, i.e., the first fork() takes around 359 milliseconds and the
nested fork() takes around 263 milliseconds. Replacing the nested fork()
and exec() with posix_spawn() reduces the time consumption to 257
milliseconds!
See https://github.com/libuv/libuv/pull/3064 to know why fork() is so
slow on macOS and why posix_spawn() is a better replacement.
Another point to note is that even base::LaunchProcess() from Chromium
calls posix_spawnp() on macOS -
8f8d82dea0:base/process/launch_mac.cc;l=295-296
Change-Id: I25c6ee9629a1ae5d0c32b361b56a1ce0b4b0fd26
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3641386
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Fixes: https://github.com/electron/electron/issues/34321
Signed-off-by: Darshan Sen <raisinten@gmail.com>
* Update .patches
Co-authored-by: Darshan Sen <raisinten@gmail.com>
Co-authored-by: Cheng Zhao <zcbenz@gmail.com>
* fix: crash when renderer process is reused
Could occur when a renderer crashes and the same-origin URL is loaded again
which leads to reusing the renderer process.
* test: renderer process crash recovery
* fix: handle case which leads to render frame DCHECK
* fix: lint
Co-authored-by: samuelmaddock <samuel.maddock@gmail.com>
* ci: cache python install to better deal with download errors.
* chore: use our CDN to download python2
* build: DRY up the python install steps
* fixup backport for 19-x-y
* trigger ci
* fixup the fixup
Co-authored-by: John Kleinschmidt <jkleinsc@electronjs.org>
Co-authored-by: Samuel Attard <sattard@salesforce.com>
Co-authored-by: Cheng Zhao <zcbenz@gmail.com>
chore: add a TRACE call for crash_reporter::Start()
Initializing the crashReporter takes around 620 milliseconds on Intel
macOS. I have sent a CL to crashpad to partially fix the performance
issue in
https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3641386.
It would be beneficial to log the performance impact of this function in
the traces in case this slows down in the future.
Signed-off-by: Darshan Sen <raisinten@gmail.com>
Co-authored-by: Darshan Sen <raisinten@gmail.com>
reference: Note: It is known that having both Content-Security-Policy
and X-Content-Security-Policy or X-Webkit-CSP causes unexpected
behaviours on certain versions of browsers. Please avoid using deprecated
X-* headers. https://content-security-policy.com/
also:
1ad18486ed
Co-authored-by: Letu Ren <fantasquex@gmail.com>
fix: revert "feat: add first-instance-ack event to the `app.requestSingleInstanceLock()` flow (#34295)
* Revert "fix: requestSingleInstanceLock API ConnectNamedPipe sometimes hangs program (#33778)"
This reverts commit ffb8749243.
* fix: revert "feat: add first-instance-ack event to the `app.requestSingleInstanceLock()` flow"
* chore: update patch
The isFocused() method on macOS works by checking if the selected
BrowserWindow is a key window. Unfortunately, this didn't work well
with blur() because it wasn't calling any macOS APIs that would change
the key status of the window. Hence, this changes the implementation of
blur() to call orderOut first, which removes the key
status of the window. Then when the orderBack function is called, it
moves the window to the back of its level in the screen list, without
changing the key window.
Fixes: https://github.com/electron/electron/issues/33732
Signed-off-by: Darshan Sen <raisinten@gmail.com>
Co-authored-by: Darshan Sen <raisinten@gmail.com>
* build: improve CI speeds and reduce CI costs (#33904)
* rely on src cache instead of workspace
* run some tasks in the background and "thread join" later
* merge some ninja build commands to reduce overhead
* remove third_party/electron_node:overlapped-checker
Target is not present in older branches
Co-authored-by: Samuel Attard <sam@electronjs.org>
Co-authored-by: John Kleinschmidt <jkleinsc@electronjs.org>
* chore: bump chromium in DEPS to 102.0.5005.3
* chore: bump chromium in DEPS to 102.0.5005.2
* chore: bump chromium in DEPS to 102.0.5005.12
* chore: bump chromium to 102.0.4999.0 (main) (#33731)
* chore: bump chromium in DEPS to 102.0.4999.0
* 3576640: Set OOM handler during V8 initialization
https://chromium-review.googlesource.com/c/chromium/src/+/3576640
* 3574964: Remove deprecated base::Value usage in print_settings_conversion code.
https://chromium-review.googlesource.com/c/chromium/src/+/3574964
* 3570062: Replicate Active state to render process for all RenderViews.
https://chromium-review.googlesource.com/c/chromium/src/+/3570062
* chore: fixup patch indices
* 3380402: Remove legacy SwiftShader
https://chromium-review.googlesource.com/c/chromium/src/+/3380402
* 3570254: [Local Fonts] Rename permission name from FONT_ACCESS to LOCAL_FONTS.
https://chromium-review.googlesource.com/c/chromium/src/+/3570254
* 3572172: Rename or remove several parameters involved in creation of MimeHandler streams
https://chromium-review.googlesource.com/c/chromium/src/+/3572172
* fix: add missing base/bits include
* chore: fix lint
* chore: remove ia32 Linux support
* chore: patch out swift-format cipd dep on macOS
* build: apply patch better
* build: reset all caches
* build: update zip manifests to remove swiftshared libraries
Refs: https://chromium-review.googlesource.com/c/chromium/src/+/3380402
* Revert "build: update zip manifests to remove swiftshared libraries"
This reverts commit 6aeec01ef1a79425a7b7d8c1cfb131a26b91c494.
* Revert "3380402: Remove legacy SwiftShader"
This reverts commit 4c7eebbbf2d0a459cc192959e17ae20f970c2da2.
* build: remove unused swiftshader egl libraries
Co-authored-by: electron-roller[bot] <84116207+electron-roller[bot]@users.noreply.github.com>
Co-authored-by: Shelley Vohr <shelley.vohr@gmail.com>
Co-authored-by: Samuel Attard <sattard@salesforce.com>
(cherry picked from commit f3e0517b6e)
* chore: update patch after cherry-pick from main roller pr
Co-authored-by: electron-roller[bot] <84116207+electron-roller[bot]@users.noreply.github.com>
Co-authored-by: John Kleinschmidt <jkleinsc@electronjs.org>
* chore: bump chromium in DEPS to 102.0.4975.0
* chore: bump chromium in DEPS to 102.0.4977.0
* chore: bump chromium in DEPS to 102.0.4979.0
* chore: bump chromium in DEPS to 102.0.4981.0
* chore: bump chromium in DEPS to 102.0.4983.0
* chore: bump chromium in DEPS to 102.0.4985.0
* chore: bump chromium in DEPS to 102.0.4987.0
* chore: bump chromium in DEPS to 102.0.4989.0
* chore: bump chromium in DEPS to 102.0.4991.0
* chore: bump chromium in DEPS to 102.0.4993.0
* chore: bump chromium in DEPS to 102.0.4995.0
* chore: bump chromium in DEPS to 102.0.4997.0
* chore: bump chromium in DEPS to 102.0.4999.0
* chore: bump chromium in DEPS to 102.0.5001.0
* chore: bump chromium in DEPS to 102.0.5003.0
* chore: bump chromium in DEPS to 102.0.5005.0
* chore: bump chromium in DEPS to 102.0.5005.3
* chore: bump chromium to 102.0.4989.0 (main) (#33557)
* chore: bump chromium in DEPS to 102.0.4975.0
* chore: bump chromium in DEPS to 102.0.4977.0
* chore: update patches
* Remove parameter of OnGpuProcessCrashed()
https://chromium-review.googlesource.com/c/chromium/src/+/3543396
* hid: Add exclusionFilters option to requestDevice
https://chromium-review.googlesource.com/c/chromium/src/+/3478175
* chore: bump chromium in DEPS to 102.0.4979.0
* chore: bump chromium in DEPS to 102.0.4981.0
* chore: update patches
* Deny notification/push permission for documents in non-standard StoragePartitions
https://chromium-review.googlesource.com/c/chromium/src/+/3257305
* Improve FrameTreeNode tracking in URLLoaderNetworkContext
https://chromium-review.googlesource.com/c/chromium/src/+/3341866
* fixup! Remove parameter of OnGpuProcessCrashed()
* chore: fix lint
* Reland "Use gfx::Insets[F]::TLBR() and gfx::Insets[F]::VH() in the rest of Chrome"
https://chromium-review.googlesource.com/c/chromium/src/+/3554236
* chore: bump chromium in DEPS to 102.0.4983.0
* Ensure EyeDropperView does not access a destroyed window
https://chromium-review.googlesource.com/c/chromium/src/+/3561542
* ci: don't delete dawn .git directory
83901: Adds a generated file with the dawn git hash encoded at build time. | https://dawn-review.googlesource.com/c/dawn/+/83901
* ci: update Windows toolchain
3550827: New toolchain for Windows 10 20348 SDK | https://chromium-review.googlesource.com/c/chromium/src/+/3550827
* chore: bump chromium in DEPS to 102.0.4985.0
* chore: update patches
* chore: bump chromium in DEPS to 102.0.4987.0
* chore: update patches
* 3563432: codehealth: remove uses of DictionaryValue in cbui/webui
https://chromium-review.googlesource.com/c/chromium/src/+/3563432
* chore: update patches after rebase
* Use gfx::Insets[F]::TLBR() and gfx::Insets[F]::VH() in the rest of Chrome
https://chromium-review.googlesource.com/c/chromium/src/+/3554236
* 3565724: Preserve "proper method names" as-is in error.stack.
https://chromium-review.googlesource.com/c/v8/v8/+/3565724
* chore: bump chromium in DEPS to 102.0.4989.0
* chore: update patches
* fixup ci: don't delete dawn .git directory for Windows
* 3560843: Remove multi-parameter version of gfx::Rect[F]::Inset()
https://chromium-review.googlesource.com/c/chromium/src/+/3560843
* 3572711: Remove unused IDS_PDF_TOOLTIP_ROTATE_CW resource.
https://chromium-review.googlesource.com/c/chromium/src/+/3572711
* 3572926: Reland "[Sysroot] Switch to Debian Bullseye stable"
https://chromium-review.googlesource.com/c/chromium/src/+/3572926
* build: fixup sysroots with electron specific dependencies
* fixup Remove multi-parameter version of gfx::Rect[F]::Inset()
* fixup 3565724: Preserve "proper method names" as-is in error.stack.
* fixup Remove multi-parameter version of gfx::Rect[F]::Inset()
* test: add spec for navigator.hid.requestDevice({ exclusionFilters: [...] }
* fixup 3565724: Preserve "proper method names" as-is in error.stack.
* ci: use python3 to get the windows toolchain profile
3525960: Explicitly run everything with python3 | https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/3525960
* chore: add diagnostic logging
* fix: try calling process.crash()
* chore: remove logging
Co-authored-by: electron-roller[bot] <84116207+electron-roller[bot]@users.noreply.github.com>
Co-authored-by: deepak1556 <hop2deep@gmail.com>
Co-authored-by: John Kleinschmidt <jkleinsc@electronjs.org>
Co-authored-by: PatchUp <73610968+patchup[bot]@users.noreply.github.com>
Co-authored-by: Shelley Vohr <shelley.vohr@gmail.com>
(cherry picked from commit 59dd17f2cf)
* chore: update patches after rebase
* chore: bump chromium in DEPS to 102.0.5005.3
* Revert "chore: bump chromium in DEPS to 102.0.5005.3"
This reverts commit 958cfb2aff.
Co-authored-by: electron-roller[bot] <84116207+electron-roller[bot]@users.noreply.github.com>
Co-authored-by: John Kleinschmidt <jkleinsc@electronjs.org>
* build: explicitly run scripts with python3
* chore: update patches
Co-authored-by: Jeremy Rose <nornagon@nornagon.net>
Co-authored-by: PatchUp <73610968+patchup[bot]@users.noreply.github.com>
* chore: bump chromium in DEPS to 102.0.4973.0
* chore: bump chromium to 102.0.4971.0 (main) (#33454)
* chore: bump chromium in DEPS to 102.0.4965.0
* chore: 3-way merge of chromium/printing.patch
* chore: update patch shear in chromium/picture-in-picture.patch
* chore: update patches
* 3101519: Window Placement: Prototype fullscreen companion window support
Xref: https://chromium-review.googlesource.com/c/chromium/src/+/3101519
build: add popup_preventer.cc, .h to our library. It's needed because
FullscreenController, we were already using, started aggregating a
PopupPreventer in 3101519.
* chore: bump chromium in DEPS to 102.0.4967.0
* Revert "3101519: Window Placement: Prototype fullscreen companion window support"
This reverts commit fc215cb99c464e939882ed3f5cf8e9874a8e3311.
Adding popup_preventer might not be the right solution; there are
cascading dependencies.
* 3551449: Add service-based usage for system print settings
Xref: https://chromium-review.googlesource.com/c/chromium/src/+/3551449
chore: fix code shear in patches/chromium/printing.patch
* chore: update patches
* chore: bump chromium in DEPS to 102.0.4969.0
* chore: update patches
* chore: bump chromium in DEPS to 102.0.4971.0
* chore: update fix_patch_out_permissions_checks_in_exclusive_access.patch
Refs https://chromium-review.googlesource.com/c/chromium/src/+/3101519
PopupunderPreventer is not useful in //electron since the window
attributes are controlled by the user via setWindowOpenHandler.
* chore: update patches
* Add FirstPartySetsHandler as a interface class in content API.
https://chromium-review.googlesource.com/c/chromium/src/+/3503410
* Create a new MediaStreamRequestType for GetOpenDevice
https://chromium-review.googlesource.com/c/chromium/src/+/3541939
* Support site isolation for <webview> tags in WebViewRendererState.
https://chromium-review.googlesource.com/c/chromium/src/+/3537735
* ci: update xcode version
Refs https://chromium-review.googlesource.com/c/chromium/src/+/3544199https://developer.apple.com/documentation/screencapturekit/capturing_screen_content_in_macos
Co-authored-by: electron-roller[bot] <84116207+electron-roller[bot]@users.noreply.github.com>
Co-authored-by: Charles Kerr <charles@charleskerr.com>
Co-authored-by: PatchUp <73610968+patchup[bot]@users.noreply.github.com>
Co-authored-by: deepak1556 <hop2deep@gmail.com>
(cherry picked from commit b711860d21)
Co-authored-by: electron-roller[bot] <84116207+electron-roller[bot]@users.noreply.github.com>
* chore: update node types version
* update express types to solve type conflict
* one more yarn.lock type bump
* update another types package to fix incompatible global declarations
* remove incompatible type magicks
* update our ambient types to match the node types
* fix test type
Rule 13 recommends using Node's URL parser for handling url inputs. At
the moment, this is not being followed in the code example for rule 5,
which falls back on checking that the url ends with a '/'. If this was
forgotten when a user copies this code it could introduce security
vulnerabilities if an attacker uses an URL in the following way:
"https://example.com.attacker.com"
Using Node's URL parser fixes this potential missuse and enables the
'/' to be omited from the code example.
Co-authored-by: Baitinq <you@example.com>
* fix: don't call X11 functions in file dialog and message box
* refactor: remove unused GtkUiPlatform declaration
* fix: set gtk darktheme only when running under X11
* fix: replace X11 window state watcher with implementation using ozone
* fix: make sure global menu barr is used only when supported
* fix: don't call X11 function in native window views under wayland
* style: fix lint issues
* fix: use GtkUiPlatform::ShowGtkWindow instead of gtk_window_present directly
* refactor: extract CreateGlobalMenuBar into separate function
* refactor: move checking for WaylandWindowDecorations inside class
* fix: check if we run under X11 only in ozone build
* refactor: drop including unused ui/base/ui_base_features.h header
* fix: modify ui_gtk_public_header.patch to also export gtk_ui.h
* fix: refactor guarding of X11 calls
- Introduce patch exposing new electron_can_call_x11 property
- Replace defined(USE_OZONE) with BUILDFLAG(OZONE_PLATFORM_X11) flags
* fix: remove the last remaining usage of USE_X11
* fix: usage of BUILDFLAG(OZONE_PLATFORM_X11) not building on non ozone
* fix: call UpdateWindowState from OnBoundsChanged only under X11
* fix: initialize asar support in worker threads
Use `ObjectWrap` instead of gin's Wrap in `electron_api_asar.cc` because
gin isn't fully initialized (and apparently not possible to initialize
without ruining the isolate configuration and array buffer allocator) in
worker threads. In the worker thread call `setupAsarSupport` just as we
do for the main process.
* Update lib/asar/fs-wrapper.ts
Co-authored-by: Darshan Sen <raisinten@gmail.com>
* Update patches/node/worker_thread_add_asar_support.patch
Co-authored-by: Darshan Sen <raisinten@gmail.com>
* Add a test
Co-authored-by: Darshan Sen <raisinten@gmail.com>
Co-authored-by: Fedor Indutny <79877362+indutny-signal@users.noreply.github.com>
Co-authored-by: John Kleinschmidt <jkleinsc@electronjs.org>
* fix: use stricter options in SecStaticCodeCheckValidity
* Update patches/squirrel.mac/fix_use_kseccschecknestedcode_kseccsstrictvalidate_in_the_sec.patch
Co-authored-by: John Kleinschmidt <jkleinsc@electronjs.org>
Co-authored-by: John Kleinschmidt <jkleinsc@electronjs.org>
* fix: ensure ElectronBrowser mojo service is only bound to authorized render frames
Notes: no-notes
* refactor: extract electron API IPC to its own mojo interface
* fix: just check main frame not primary main frame
* fix: race condition where webContents can be nullptr during re-focus and a multi-window close sequence
* chore: update electron_inspectable_web_contents_view.mm
* docs: Updated list numbering
The steps to package and distribute an application using electron had incorrect numbering
* Indented text within ordered list sections
* Removed single space
* Fixed indentation
* build: remove use_thin_lto = false
* ci: enabling if things get really bad (all darwin)
* build: lol don't enable that
* build: add patch to disable thin lto for mac
* feat: Added ability to configure if window should close when opener closes
* fix: check if embedder is destroyed
* fix: correctly take over closeWithOpener property
* chore: Added documentation
* Update docs/api/window-open.md
Co-authored-by: John Kleinschmidt <jkleinsc@github.com>
* chore: refactor
Co-authored-by: Jeremy Rose <nornagon@nornagon.net>
* chore: changed property name from `closeWithOpener` to `outlivesOpener`
* dummy change to kick lint
* undo above
Co-authored-by: John Kleinschmidt <jkleinsc@github.com>
Co-authored-by: Jeremy Rose <nornagon@nornagon.net>
This commit backports three commits from libuv's 1.x branch to fix
issues with CPU going to 100% on macOS when EPROTOTYPE is returned.
See: abb109f30f
See: 3a7b95593a
See: de24da8c11
* build: add stack_trace.h to main delegate
* build: trigger circleci
* build: free up a tiny bit more space
* build: disable use_thin_lto
* fixup build/args/all.gn
Co-authored-by: Samuel Attard <sam@electronjs.org>
Co-authored-by: John Kleinschmidt <jkleinsc@electronjs.org>
* docs: add IPC doc
* fix: use "string" primitive
* use 'string' ipcrenderer
* use "number" primitive
* Update docs/tutorial/ipc.md
Co-authored-by: Jeremy Rose <nornagon@nornagon.net>
* Update docs/tutorial/ipc.md
Co-authored-by: Jeremy Rose <nornagon@nornagon.net>
* add code sample
Co-authored-by: Jeremy Rose <nornagon@nornagon.net>
* build: rebuild the dist_zips when the deps get modified
The dist.zip generated by the electron_dist_zip action was not getting
updated when changes were being made to the dependencies, like the
source files. It turns out, we were using data_deps for the dependencies
instead of deps. Here is the difference:
data_deps: things needed to ultimately run the thing built by a target
deps: things needed to build the target
So the difference in treatment of both sets of dependencies is actually
intentional.
Signed-off-by: Darshan Sen <raisinten@gmail.com>
* fixup! build: rebuild the dist_zips when the deps get modified
Signed-off-by: Darshan Sen <raisinten@gmail.com>
test: add focus and blur WebContents event tests
test: confirm that webcontents focus event is fired on browserwindow focus
fix: mac focus event test timeout
* Update context bridge docs about Promises
From my testing it doesn't remove Promises in nested objects,
also according to the test suite it does not:
80577a4f08/spec-main/api-context-bridge-spec.ts (L693)
* docs: Update docs for errors too
* fix: re-enable PartitionAlloc on macOS
* no need to copy ignore_result on linux
* factor out FixStdioStreams
* include buildflags.h in electron_main_linux
* #include electron/fuses
* more missing includes
* script: Python3 compatibility for utf8 conversion
The unicode() method has been renamed to str() in Python3,
add a wrapper around it to support running against both versions.
* script: don't require python2 for git-[import,export]-patches
The scripts work just fine with python3 too, so use the generic
python executable as the script interpreter.
Most setups don't even require or provide python 2 anymore,
so this saves one from having to install it just for the scripts.
* feat: Add onFirstInstanceAck event for requestSingleInstanceLock
* Add tests
* Apply patch fix
* Add back missing docs
* Rebase
* Listen for exit earlier in test
* Rebase
* fix: Don't create console window when creating process
* Update patches/node/fix_don_t_create_console_window_when_creating_process.patch
Co-authored-by: Robo <hop2deep@gmail.com>
* Remove extra line in description
Co-authored-by: Robo <hop2deep@gmail.com>
CFLocaleGetValue() returned null and crashed the process when
app.getLocaleCountryCode() was run on a CircleCI metal resource class
macOS instance with Xcode 12.5.1. This change fixes that logic and adds
further checks to make the code future-proof.
Here too people are complaining that the returned country code migth be
null: https://stackoverflow.com/questions/15202454/nslocalecountrycode-returns-nil
Signed-off-by: Darshan Sen <darshan.sen@postman.com>
WebRTC has changed how they integrate into Chromium, they don't
expose their dependencies externally anymore. Instead, one must
now go through webrtc_overrides:
https://chromium.googlesource.com/chromium/src.git/+/cbc90fd093956
We're already including webrtc_overrides as a dependency which
includes the modules, so this extra deps isn't needed anymore.
In the synchronous code path, gtk_native_dialog_run() will call
gtk_native_dialog_show(). Previously this was causing an assertion to be
hit at run time.
* build: account for path-filtering workflow in release-build script
* build: update syntax for workflow id
Co-authored-by: John Kleinschmidt <jkleinsc@electronjs.org>
Co-authored-by: John Kleinschmidt <jkleinsc@electronjs.org>
Add the native frame border size to the minimum and maximum size if
the view reports its size as the client size. It allows to enlarge
window to proper values when aspect ratio and max width/height are
set. It also fixes DCHECK which was triggered when user tried to
enlarge window above dimensions set during creation of the
BrowserWindow.
description:What version of Electron are you using?
placeholder:12.0.0
description:|
What version of Electron are you using?
Note: Please only report issues for [currently supported versions of Electron](https://www.electronjs.org/docs/latest/tutorial/support#currently-supported-versions).
placeholder:17.0.0
validations:
required:true
- type:dropdown
@@ -53,7 +56,7 @@ body:
attributes:
label:Last Known Working Electron version
description:What is the last version of Electron this worked in, if applicable?
Each Electron release provides binaries for macOS, Windows, and Linux.
* macOS (El Capitan and up): Electron provides 64-bit Intel and ARM binaries for macOS. Apple Silicon support was added in Electron 11.
* Windows (Windows 7 and up): Electron provides `ia32` (`x86`), `x64` (`amd64`), and `arm64` binaries for Windows. Windows on ARM support was added in Electron 5.0.8.
* Linux: The prebuilt binaries of Electron are built on Ubuntu 20.04. They have also been verified to work on:
* Ubuntu 14.04 and newer
* Fedora 24 and newer
* Debian 8 and newer
## Quick start & Electron Fiddle
Use [`Electron Fiddle`](https://github.com/electron/fiddle)
@@ -54,12 +65,10 @@ npm start
## Resources for learning Electron
- [electronjs.org/docs](https://electronjs.org/docs) - All of Electron's documentation
- [electron/fiddle](https://github.com/electron/fiddle) - A tool to build, run, and package small Electron experiments
- [electron/electron-quick-start](https://github.com/electron/electron-quick-start) - A very basic starter Electron app
- [electronjs.org/community#boilerplates](https://electronjs.org/community#boilerplates) - Sample starter apps created by the community
- [electron/simple-samples](https://github.com/electron/simple-samples) - Small applications with ideas for taking them further
- [electron/electron-api-demos](https://github.com/electron/electron-api-demos) - An Electron app that teaches you how to use Electron
* [electronjs.org/docs](https://electronjs.org/docs) - All of Electron's documentation
* [electron/fiddle](https://github.com/electron/fiddle) - A tool to build, run, and package small Electron experiments
* [electron/electron-quick-start](https://github.com/electron/electron-quick-start) - A very basic starter Electron app
* [electronjs.org/community#boilerplates](https://electronjs.org/community#boilerplates) - Sample starter apps created by the community
When using the Electron or other GitHub logos, be sure to follow the [GitHub logo guidelines](https://github.com/logos).
When using Electron logos, make sure to follow [OpenJS Foundation Trademark Policy](https://openjsf.org/wp-content/uploads/sites/84/2021/01/OpenJS-Foundation-Trademark-Policy-2021-01-12.docx.pdf).
# CalculateNativeWinOcclusion is disabled due to https://bugs.chromium.org/p/chromium/issues/detail?id=1139022
- if "%RUN_TESTS%"=="true" ( echo Running test suite & node script/yarn test -- --trace-uncaught --enable-logging --disable-features=CalculateNativeWinOcclusion )
- if "%RUN_TESTS%"=="true" ( echo Running main test suite & node script/yarn test -- --trace-uncaught --runners=main --enable-logging=file --log-file=%cd%\electron.log --disable-features=CalculateNativeWinOcclusion )
- if "%RUN_TESTS%"=="true" ( echo Running remote test suite & node script/yarn test -- --trace-uncaught --runners=remote --runTestFilesSeperately --enable-logging=file --log-file=%cd%\electron.log --disable-features=CalculateNativeWinOcclusion )
- if "%RUN_TESTS%"=="true" ( echo Running native test suite & node script/yarn test -- --trace-uncaught --runners=native --enable-logging=file --log-file=%cd%\electron.log --disable-features=CalculateNativeWinOcclusion )
- cd ..
- if "%RUN_TESTS%"=="true" ( echo Verifying non proprietary ffmpeg & python electron\script\verify-ffmpeg.py --build-dir out\Default --source-root %cd% --ffmpeg-path out\ffmpeg )
- echo "About to verify mksnapshot"
@@ -221,9 +220,9 @@ deploy_script:
- cd electron
- ps:>-
if (Test-Path Env:\ELECTRON_RELEASE) {
if (Test-Path Env:\UPLOAD_TO_S3) {
Write-Output "Uploading Electron release distribution to s3"
@@ -690,7 +690,7 @@ Overrides the current application's name.
### `app.getLocale()`
Returns `string` - The current application locale, fetched using Chromium's `l10n_util` library.
Possible return values are documented [here](https://source.chromium.org/chromium/chromium/src/+/master:ui/base/l10n/l10n_util.cc).
Possible return values are documented [here](https://source.chromium.org/chromium/chromium/src/+/main:ui/base/l10n/l10n_util.cc).
To set the locale, you'll want to use a command line switch at app startup, which may be found [here](command-line-switches.md).
@@ -837,6 +837,8 @@ Returns `Object`:
*`categories` [JumpListCategory[]](structures/jump-list-category.md) | `null` - Array of `JumpListCategory` objects.
Returns `string`
Sets or removes a custom Jump List for the application, and returns one of the
following strings:
@@ -1057,7 +1059,7 @@ Activation policy types:
Imports the certificate in pkcs12 format into the platform certificate store.
`callback` is called with the `result` of import operation, a value of `0`
indicates success while any other value indicates failure according to Chromium [net_error_list](https://source.chromium.org/chromium/chromium/src/+/master:net/base/net_error_list.h).
indicates success while any other value indicates failure according to Chromium [net_error_list](https://source.chromium.org/chromium/chromium/src/+/main:net/base/net_error_list.h).
* Options are listed in [SkParseColor.cpp](https://source.chromium.org/chromium/chromium/src/+/main:third_party/skia/src/utils/SkParseColor.cpp;l=11-152;drc=eea4bf52cb0d55e2a39c828b017c80a5ee054148)
* Similar to CSS Color Module Level 3 keywords, but case-sensitive.
* e.g. `blueviolet` or `red`
**Note:** Hex format with alpha takes `AARRGGBB` or `ARGB`, _not_`RRGGBBA` or `RGA`.
Note that even for apps that use `ready-to-show` event, it is still recommended
to set `backgroundColor` to make app feel more native.
to set `backgroundColor` to make the app feel more native.
Some examples of valid `backgroundColor` values include:
```js
constwin=newBrowserWindow()
win.setBackgroundColor('hsl(230, 100%, 50%)')
win.setBackgroundColor('rgb(255, 145, 145)')
win.setBackgroundColor('#ff00a3')
win.setBackgroundColor('blueviolet')
```
For more information about these color types see valid options in [win.setBackgroundColor](browser-window.md#winsetbackgroundcolorbackgroundcolor).
## Parent and child windows
@@ -146,20 +158,20 @@ It creates a new `BrowserWindow` with native properties as set by the `options`.
*`useContentSize` boolean (optional) - The `width` and `height` would be used as web
page's size, which means the actual window's size will include window
frame's size and be slightly larger. Default is `false`.
*`center` boolean (optional) - Show window in the center of the screen.
*`center` boolean (optional) - Show window in the center of the screen. Default is `false`.
*`minWidth` Integer (optional) - Window's minimum width. Default is `0`.
*`minHeight` Integer (optional) - Window's minimum height. Default is `0`.
*`maxWidth` Integer (optional) - Window's maximum width. Default is no limit.
*`maxHeight` Integer (optional) - Window's maximum height. Default is no limit.
*`resizable` boolean (optional) - Whether window is resizable. Default is `true`.
*`movable` boolean (optional) - Whether window is movable. This is not implemented
on Linux. Default is `true`.
*`minimizable` boolean (optional) - Whether window is minimizable. This is not
implemented on Linux. Default is `true`.
*`maximizable` boolean (optional) - Whether window is maximizable. This is not
implemented on Linux. Default is `true`.
*`closable` boolean (optional) - Whether window is closable. This is not implemented
on Linux. Default is `true`.
*`movable` boolean (optional) _macOS__Windows_ - Whether window is
movable. This is not implemented on Linux. Default is `true`.
*`minimizable` boolean (optional) _macOS__Windows_ - Whether window is
minimizable. This is not implemented on Linux. Default is `true`.
*`maximizable` boolean (optional) _macOS__Windows_ - Whether window is
maximizable. This is not implemented on Linux. Default is `true`.
*`closable` boolean (optional) _macOS__Windows_ - Whether window is
closable. This is not implemented on Linux. Default is `true`.
*`focusable` boolean (optional) - Whether the window can be focused. Default is
`true`. On Windows setting `focusable: false` also implies setting
`skipTaskbar: true`. On Linux setting `focusable: false` makes the window
@@ -173,9 +185,10 @@ It creates a new `BrowserWindow` with native properties as set by the `options`.
*`fullscreenable` boolean (optional) - Whether the window can be put into fullscreen
mode. On macOS, also whether the maximize/zoom button should toggle full
screen mode or maximize window. Default is `true`.
*`simpleFullscreen` boolean (optional) - Use pre-Lion fullscreen on macOS. Default is `false`.
*`skipTaskbar` boolean (optional) - Whether to show the window in taskbar. Default is
`false`.
*`simpleFullscreen` boolean (optional)_macOS_ - Use pre-Lion fullscreen on
macOS. Default is`false`.
*`skipTaskbar` boolean (optional) _macOS__Windows_ - Whether to show the window in taskbar.
Default is `false`.
*`kiosk` boolean (optional) - Whether the window is in kiosk mode. Default is `false`.
*`title` string (optional) - Default window title. Default is `"Electron"`. If the HTML tag `<title>` is defined in the HTML file loaded by `loadURL()`, this property will be ignored.
*`icon` ([NativeImage](native-image.md) | string) (optional) - The window icon. On Windows it is
@@ -189,29 +202,30 @@ It creates a new `BrowserWindow` with native properties as set by the `options`.
*`parent` BrowserWindow (optional) - Specify parent window. Default is `null`.
*`modal` boolean (optional) - Whether this is a modal window. This only works when the
window is a child window. Default is `false`.
*`acceptFirstMouse` boolean (optional) - Whether clicking an inactive window will also
click through to the web contents. Default is`false` on macOS. This option is not
configurable on other platforms.
*`acceptFirstMouse` boolean (optional)_macOS_ - Whether clicking an
inactive window will also click through to the web contents. Default is
`false` on macOS. This option is not configurable on other platforms.
*`disableAutoHideCursor` boolean (optional) - Whether to hide cursor when typing.
Default is `false`.
*`autoHideMenuBar` boolean (optional) - Auto hide the menu bar unless the `Alt`
key is pressed. Default is `false`.
*`enableLargerThanScreen` boolean (optional) - Enable the window to be resized larger
than screen. Only relevant for macOS, as other OSes allow
larger-than-screen windows by default. Default is `false`.
*`backgroundColor` string (optional) - Window's background color as a hexadecimal value,
like `#66CD00` or `#FFF` or `#80FFFFFF` (alpha in #AARRGGBB format is supported if
`transparent` is set to `true`). Default is `#FFF` (white).
*`enableLargerThanScreen` boolean (optional)_macOS_ - Enable the window to
be resized larger than screen. Only relevant for macOS, as other OSes
allow larger-than-screen windows by default. Default is `false`.
*`backgroundColor` string (optional) - The window's background color in Hex, RGB, RGBA, HSL, HSLA or named CSS color format. Alpha in #AARRGGBB format is supported if `transparent` is set to `true`. Default is `#FFF` (white). See [win.setBackgroundColor](browser-window.md#winsetbackgroundcolorbackgroundcolor) for more information.
*`hasShadow` boolean (optional) - Whether window should have a shadow. Default is `true`.
*`opacity` number (optional) - Set the initial opacity of the window, between 0.0 (fully
transparent) and 1.0 (fully opaque). This is only implemented on Windows and macOS.
*`opacity` number (optional) _macOS__Windows_ - Set the initial opacity of
the window, between 0.0 (fully transparent) and 1.0 (fully opaque). This
is only implemented on Windows and macOS.
*`darkTheme` boolean (optional) - Forces using dark theme for the window, only works on
some GTK+3 desktop environments. Default is `false`.
*`transparent` boolean (optional) - Makes the window [transparent](../tutorial/window-customization.md#create-transparent-windows).
Default is `false`. On Windows, does not work unless the window is frameless.
*`type` string (optional) - The type of window, default is normal window. See more about
this below.
*`visualEffectState` string (optional) - Specify how the material appearance should reflect window activity state on macOS. Must be used with the `vibrancy` property. Possible values are:
*`visualEffectState` string (optional)_macOS_ - Specify how the material
appearance should reflect window activity state on macOS. Must be used
with the `vibrancy` property. Possible values are:
*`followWindow` - The backdrop should automatically appear active when the window is active, and inactive when it is not. This is the default.
*`active` - The backdrop should always appear active.
*`inactive` - The backdrop should always appear inactive.
@@ -219,36 +233,41 @@ It creates a new `BrowserWindow` with native properties as set by the `options`.
Default is `default`. Possible values are:
*`default` - Results in the standard title bar for macOS or Windows respectively.
*`hidden` - Results in a hidden title bar and a full size content window. On macOS, the window still has the standard window controls (“traffic lights”) in the top left. On Windows, when combined with `titleBarOverlay: true` it will activate the Window Controls Overlay (see `titleBarOverlay` for more information), otherwise no window controls will be shown.
*`hiddenInset` - Only on macOS, results in a hidden title bar with an alternative look
where the traffic light buttons are slightly more inset from the window edge.
*`customButtonsOnHover` - Only on macOS, results in a hidden title bar and a full size
content window, the traffic light buttons will display when being hovered
over in the top left of the window. **Note:** This option is currently
experimental.
*`trafficLightPosition` [Point](structures/point.md) (optional) - Set a
custom position for the traffic light buttons in frameless windows.
*`roundedCorners` boolean (optional) - Whether frameless window should have
rounded corners on macOS. Default is `true`.
*`fullscreenWindowTitle` boolean (optional) _Deprecated_ - Shows the title in
the title bar in fullscreen mode on macOS for `hiddenInset` titleBarStyle.
Default is `false`.
*`hiddenInset`_macOS_ - Only on macOS, results in a hidden title bar
with an alternative look where the traffic light buttons are slightly
more inset from the window edge.
*`customButtonsOnHover`_macOS_ - Only on macOS, results in a hidden
title bar and a full size content window, the traffic light buttons will
display when being hovered over in the top left of the window.
the title in the title bar in full screen mode on macOS for `hiddenInset`
titleBarStyle. Default is `false`.
*`thickFrame` boolean (optional) - Use `WS_THICKFRAME` style for frameless windows on
Windows, which adds standard window frame. Setting it to `false` will remove
window shadow and window animations. Default is `true`.
*`vibrancy` string (optional) - Add a type of vibrancy effect to the window, only on
macOS. Can be `appearance-based`, `light`, `dark`,`titlebar`, `selection`,
`menu`, `popover`, `sidebar`, `medium-light`, `ultra-dark`, `header`, `sheet`, `window`, `hud`, `fullscreen-ui`, `tooltip`, `content`, `under-window`, or `under-page`. Please note that `appearance-based`, `light`, `dark`, `medium-light`, and `ultra-dark` are deprecated and have been removed in macOS Catalina (10.15).
*`zoomToPageWidth` boolean (optional) - Controls the behavior on macOS when
option-clicking the green stoplight button on the toolbar or by clicking the
Window > Zoom menu item. If `true`, the window will grow to the preferred
width of the web page when zoomed, `false` will cause it to zoom to the
width of the screen. This will also affect the behavior when calling
`maximize()` directly. Default is `false`.
*`tabbingIdentifier` string (optional) - Tab group name, allows opening the
window as a native tab on macOS 10.12+. Windows with the same tabbing
identifier will be grouped together. This also adds a native new tab button
to your window's tab bar and allows your `app` and window to receive the
`new-window-for-tab` event.
*`vibrancy` string (optional)_macOS_ - Add a type of vibrancy effect to
the window, only on macOS. Can be `appearance-based`, `light`, `dark`,
`tooltip`, `content`, `under-window`, or `under-page`. Please note that
`appearance-based`, `light`, `dark`, `medium-light`, and `ultra-dark` are
deprecated and have been removed in macOS Catalina (10.15).
*`zoomToPageWidth` boolean (optional) _macOS_ - Controls the behavior on
macOS when option-clicking the green stoplight button on the toolbar or by
clicking the Window > Zoom menu item. If `true`, the window will grow to
the preferred width of the web page when zoomed, `false` will cause it to
zoom to the width of the screen. This will also affect the behavior when
calling `maximize()` directly. Default is `false`.
*`tabbingIdentifier` string (optional) _macOS_ - Tab group name, allows
opening the window as a native tab on macOS 10.12+. Windows with the same
tabbing identifier will be grouped together. This also adds a native new
tab button to your window's tab bar and allows your `app` and window to
receive the `new-window-for-tab` event.
*`webPreferences` Object (optional) - Settings of web page's features.
*`devTools` boolean (optional) - Whether to enable DevTools. If it is set to `false`, can not use `BrowserWindow.webContents.openDevTools()` to open DevTools. Default is `true`.
*`nodeIntegration` boolean (optional) - Whether node integration is enabled.
@@ -300,8 +319,8 @@ It creates a new `BrowserWindow` with native properties as set by the `options`.
*`plugins` boolean (optional) - Whether plugins should be enabled. Default is `false`.
(rubber banding) effect on macOS. Default is `false`.
*`enableBlinkFeatures` string (optional) - A list of feature strings separated by `,`, like
`CSSVariables,KeyboardEventKey` to enable. The full list of supported feature
strings can be found in the [RuntimeEnabledFeatures.json5][runtime-enabled-features]
@@ -341,9 +360,6 @@ It creates a new `BrowserWindow` with native properties as set by the `options`.
[Chrome Content Scripts][chrome-content-scripts]. You can access this
context in the dev tools by selecting the 'Electron Isolated Context'
entry in the combo box at the top of the Console tab.
*`nativeWindowOpen` boolean (optional) - Whether to use native
`window.open()`. Defaults to `true`. Child windows will always have node
integration disabled unless `nodeIntegrationInSubFrames` is true.
*`webviewTag` boolean (optional) - Whether to enable the [`<webview>` tag](webview-tag.md).
Defaults to `false`. **Note:** The
`preload` script configured for the `<webview>` will have node integration
@@ -391,9 +407,10 @@ It creates a new `BrowserWindow` with native properties as set by the `options`.
contain the layout of the document—without requiring scrolling. Enabling
this will cause the `preferred-size-changed` event to be emitted on the
`WebContents` when the preferred size changes. Default is `false`.
*`titleBarOverlay` Object | boolean (optional) - When using a frameless window in conjuction with `win.setWindowButtonVisibility(true)` on macOS or using a `titleBarStyle` so that the standard window controls ("traffic lights" on macOS) are visible, this property enables the Window Controls Overlay [JavaScript APIs][overlay-javascript-apis] and [CSS Environment Variables][overlay-css-env-vars]. Specifying `true` will result in an overlay with default system colors. Default is `false`.
*`color`string (optional) _Windows_ - The CSS color of the Window Controls Overlay when enabled. Default is the system color.
*`symbolColor`string (optional) _Windows_ - The CSS color of the symbols on the Window Controls Overlay when enabled. Default is the system color.
*`titleBarOverlay` Object | Boolean (optional) - When using a frameless window in conjunction with `win.setWindowButtonVisibility(true)` on macOS or using a `titleBarStyle` so that the standard window controls ("traffic lights" on macOS) are visible, this property enables the Window Controls Overlay [JavaScript APIs][overlay-javascript-apis] and [CSS Environment Variables][overlay-css-env-vars]. Specifying `true` will result in an overlay with default system colors. Default is `false`.
*`color`String (optional) _Windows_ - The CSS color of the Window Controls Overlay when enabled. Default is the system color.
*`symbolColor`String (optional) _Windows_ - The CSS color of the symbols on the Window Controls Overlay when enabled. Default is the system color.
*`height` Integer (optional) _macOS__Windows_ - The height of the title bar and Window Controls Overlay in pixels. Default is system height.
When setting minimum or maximum window size with `minWidth`/`maxWidth`/
`minHeight`/`maxHeight`, it only constrains the users. It won't prevent you from
* Options are listed in [SkParseColor.cpp](https://source.chromium.org/chromium/chromium/src/+/main:third_party/skia/src/utils/SkParseColor.cpp;l=11-152;drc=eea4bf52cb0d55e2a39c828b017c80a5ee054148)
* Similar to CSS Color Module Level 3 keywords, but case-sensitive.
* e.g. `blueviolet` or `red`
Sets the background color of the window. See [Setting `backgroundColor`](#setting-the-backgroundcolor-property).
@@ -567,7 +567,7 @@ the original network configuration.
*`errorCode` Integer - Error code.
*`callback` Function
*`verificationResult` Integer - Value can be one of certificate error codes
from [here](https://source.chromium.org/chromium/chromium/src/+/master:net/base/net_error_list.h).
from [here](https://source.chromium.org/chromium/chromium/src/+/main:net/base/net_error_list.h).
Apart from the certificate error codes, the following special codes can be used.
*`0` - Indicates success and disables Certificate Transparency verification.
*`-2` - Indicates failure.
@@ -868,6 +868,20 @@ this session just before normal `preload` scripts run.
Returns `string[]` an array of paths to preload scripts that have been
registered.
#### `ses.setCodeCachePath(path)`
*`path` String - Absolute path to store the v8 generated JS code cache from the renderer.
Sets the directory to store the generated JS [code cache](https://v8.dev/blog/code-caching-for-devs) for this session. The directory is not required to be created by the user before this call, the runtime will create if it does not exist otherwise will use the existing directory. If directory cannot be created, then code cache will not be used and all operations related to code cache will fail silently inside the runtime. By default, the directory will be `Code Cache` under the
respective user data folder.
#### `ses.clearCodeCaches(options)`
*`options` Object
*`urls` String[] (optional) - An array of url corresponding to the resource whose generated code cache needs to be removed. If the list is empty then all entries in the cache directory will be removed.
Returns `Promise<void>` - resolves when the code cache clear operation is complete.
the `enctype` attribute of the submitted HTML form.
*`boundary` string (optional) - The boundary used to separate multiple parts of
the message. Only valid when `contentType` is `multipart/form-data`.
Note that keys starting with `--` are not currently supported. For example, this will errantly submit as `multipart/form-data` when `nativeWindowOpen` is set to `false` in webPreferences:
@@ -109,9 +109,11 @@ example values of `event` are:
*`AppleColorPreferencesChangedNotification`
*`AppleShowScrollBarsSettingChanged`
If `event` is null, the `NSDistributedNotificationCenter` doesn’t use it as criteria for delivery to the observer. See [docs](https://developer.apple.com/documentation/foundation/nsnotificationcenter/1411723-addobserverforname?language=objc) for more information.
@@ -122,9 +124,11 @@ Returns `number` - The ID of this subscription
Same as `subscribeNotification`, but uses `NSNotificationCenter` for local defaults.
This is necessary for events such as `NSUserDefaultsDidChangeNotification`.
If `event` is null, the `NSNotificationCenter` doesn’t use it as criteria for delivery to the observer. See [docs](https://developer.apple.com/documentation/foundation/nsnotificationcenter/1411723-addobserverforname?language=objc) for more information.
@@ -135,6 +139,8 @@ Returns `number` - The ID of this subscription
Same as `subscribeNotification`, but uses `NSWorkspace.sharedWorkspace.notificationCenter`.
This is necessary for events such as `NSWorkspaceDidActivateApplicationNotification`.
If `event` is null, the `NSWorkspaceNotificationCenter` doesn’t use it as criteria for delivery to the observer. See [docs](https://developer.apple.com/documentation/foundation/nsnotificationcenter/1411723-addobserverforname?language=objc) for more information.
@@ -35,7 +35,7 @@ for all windows, webviews, opened devtools, and devtools extension background pa
### `webContents.getFocusedWebContents()`
Returns `WebContents` - The web contents that is focused in this application, otherwise
Returns `WebContents` | null - The web contents that is focused in this application, otherwise
returns `null`.
### `webContents.fromId(id)`
@@ -92,7 +92,7 @@ Returns:
*`frameRoutingId` Integer
This event is like `did-finish-load` but emitted when the load failed.
The full list of error codes and their meaning is available [here](https://source.chromium.org/chromium/chromium/src/+/master:net/base/net_error_list.h).
The full list of error codes and their meaning is available [here](https://source.chromium.org/chromium/chromium/src/+/main:net/base/net_error_list.h).
#### Event: 'did-fail-provisional-load'
@@ -290,7 +290,7 @@ Returns:
*`frameProcessId` Integer
*`frameRoutingId` Integer
Emitted as a server side redirect occurs during navigation. For example a 302
Emitted when a server side redirect occurs during navigation. For example a 302
redirect.
This event will be emitted after `did-start-navigation` and always before the
@@ -508,6 +508,23 @@ Returns:
Emitted when the user is requesting to change the zoom level using the mouse wheel.
#### Event: 'blur'
Emitted when the `WebContents` loses focus.
#### Event: 'focus'
Emitted when the `WebContents` gains focus.
Note that on macOS, having focus means the `WebContents` is the first responder
of window, so switching focus between windows would not trigger the `focus` and
`blur` events of `WebContents`, as the first responder of each window is not
changed.
The `focus` and `blur` events of `WebContents` should only be used to detect
focus change between different `WebContents` and `BrowserView` in the same
window.
#### Event: 'devtools-opened'
Emitted when DevTools is opened.
@@ -803,9 +820,6 @@ This event can be used to configure `webPreferences` for the `webContents`
of a `<webview>` before it's loaded, and provides the ability to set settings
that can't be set via `<webview>` attributes.
**Note:** The specified `preload` script option will appear as `preloadURL`
(not `preload`) in the `webPreferences` object emitted with this event.
*`cssOrigin` string (optional) - Can be either 'user' or 'author'. Sets the [cascade origin](https://www.w3.org/TR/css3-cascade/#cascade-origin) of the inserted stylesheet. Default is 'author'.
Returns `string` - A key for the inserted CSS that can later be used to remove
@@ -12,6 +12,47 @@ 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 (20.0)
### Default Changed: renderers without `nodeIntegration: true` are sandboxed by default
Previously, renderers that specified a preload script defaulted to being
unsandboxed. This meant that by default, preload scripts had access to Node.js.
In Electron 20, this default has changed. Beginning in Electron 20, renderers
will be sandboxed by default, unless `nodeIntegration: true` or `sandbox: false`
is specified.
If your preload scripts do not depend on Node, no action is needed. If your
preload scripts _do_ depend on Node, either refactor them to remove Node usage
from the renderer, or explicitly specify `sandbox: false` for the relevant
renderers.
### Removed: `skipTaskbar` on Linux
On X11, `skipTaskbar` sends a `_NET_WM_STATE_SKIP_TASKBAR` message to the X11
window manager. There is not a direct equivalent for Wayland, and the known
workarounds have unacceptable tradeoffs (e.g. Window.is_skip_taskbar in GNOME
requires unsafe mode), so Electron is unable to support this feature on Linux.
## Planned Breaking API Changes (19.0)
### Removed: IA32 Linux binaries
This is a result of Chromium 102.0.4999.0 dropping support for IA32 Linux.
This concludes the [removal of support for IA32 Linux](#removed-ia32-linux-support).
## Planned Breaking API Changes (18.0)
### Removed: `nativeWindowOpen`
Prior to Electron 15, `window.open` was by default shimmed to use
`BrowserWindowProxy`. This meant that `window.open('about:blank')` did not work
to open synchronously scriptable child windows, among other incompatibilities.
Since Electron 15, `nativeWindowOpen` has been enabled by default.
See the documentation for [window.open in Electron](api/window-open.md)
for more details.
## Planned Breaking API Changes (17.0)
### Removed: `desktopCapturer.getSources` in the renderer
@@ -1165,6 +1206,10 @@ not present, then the native module will fail to load on Windows, with an error
message like `Cannot find module`. See the [native module
guide](/docs/tutorial/using-native-node-modules.md) for more.
### Removed: IA32 Linux support
Electron 18 will no longer run on 32-bit Linux systems. See [discontinuing support for 32-bit Linux](https://www.electronjs.org/blog/linux-32bit-support) for more information.
## Breaking API Changes (3.0)
The following list includes the breaking API changes in Electron 3.0.
@@ -131,7 +131,7 @@ $ gn gen out/Release --args="import(\"//electron/build/args/release.gn\")"
Also you shouldn't have to run `gn gen` again—if you want to change the build arguments, you can run `gn args out/Testing` to bring up an editor. To see the list of available build configuration options, run `gn args out/Testing --list`.
**To build, run `ninja` with the `electron` target:**
Nota Bene: This will also take a while and probably heat up your lap.
Note: This will also take a while and probably heat up your lap.
For the testing configuration:
@@ -196,12 +196,12 @@ If you test other combinations and find them to work, please update this documen
See the GN reference for allowable values of [`target_os`][target_os values]
To cross-compile for Windows on Arm, [follow Chromium's guide](https://chromium.googlesource.com/chromium/src/+/refs/heads/master/docs/windows_build_instructions.md#Visual-Studio) to get the necessary dependencies, SDK and libraries, then build with `ELECTRON_BUILDING_WOA=1` in your environment before running `gclient sync`.
To cross-compile for Windows on Arm, [follow Chromium's guide](https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/windows_build_instructions.md#Visual-Studio) to get the necessary dependencies, SDK and libraries, then build with `ELECTRON_BUILDING_WOA=1` in your environment before running `gclient sync`.
If you're developing Electron and don't plan to redistribute your
custom Electron build, you may skip this section.
Official Electron builds are built with [Xcode 12.2](https://download.developer.apple.com/Developer_Tools/Xcode_12.2/Xcode_12.2.xip), and the macOS 11.0 SDK. Building with a newer SDK works too, but the releases currently use the 11.0 SDK.
@@ -9,14 +9,12 @@ Follow the guidelines below for building **Electron itself** on Windows, for the
* Windows 10 / Server 2012 R2 or higher
* Visual Studio 2017 15.7.2 or higher - [download VS 2019 Community Edition for
free](https://www.visualstudio.com/vs/)
* See [the Chromium build documentation](https://chromium.googlesource.com/chromium/src/+/master/docs/windows_build_instructions.md#visual-studio) for more details on which Visual Studio
* See [the Chromium build documentation](https://chromium.googlesource.com/chromium/src/+/main/docs/windows_build_instructions.md#visual-studio) for more details on which Visual Studio
components are required.
* If your Visual Studio is installed in a directory other than the default, you'll need to
set a few environment variables to point the toolchains to your installation path.
*`vs2019_install = DRIVE:\path\to\Microsoft Visual Studio\2019\Community`, replacing `2019` and `Community` with your installed versions and replacing `DRIVE:` with the drive that Visual Studio is on. Often, this will be `C:`.
*`WINDOWSSDKDIR = DRIVE:\path\to\Windows Kits\10`, replacing `DRIVE:` with the drive that Windows Kits is on. Often, this will be `C:`.
* [Python for Windows (pywin32) Extensions](https://pypi.org/project/pywin32/#files)
is also needed in order to run the build process.
* [Node.js](https://nodejs.org/download/)
* [Git](https://git-scm.com)
* Debugging Tools for Windows of Windows SDK 10.0.15063.468 if you plan on
description: 'To distribute your app with Electron, you need to package and rebrand it. To do this, you can either use specialized tooling or manual approaches.'
slug: application-distribution
hide_title: false
---
## Overview
To distribute your app with Electron, you need to package and rebrand it.
To do this, you can either use specialized tooling or manual approaches.
To distribute your app with Electron, you need to package and rebrand it. To do this, you
can either use specialized tooling or manual approaches.
## With tooling
You can use the following tools to distribute your application:
There are a couple tools out there that exist to package and distribute your Electron app.
We recommend using [Electron Forge](https://www.electronforge.io). You can check out
its documentation directly, or refer to the [Packaging and Distribution](./tutorial-5-packaging.md)
Your app may crash. See the Resource Access section in [Hardened Runtime](https://developer.apple.com/documentation/security/hardened_runtime) for more information and entitlements you may need.
## `electron-builder`
### Using Electron Builder
Electron Builder comes with a custom solution for signing your application. You
can find [its documentation here](https://www.electron.build/code-signing).
## `electron-packager`
### Using Electron Packager
If you're not using an integrated build pipeline like Forge or Builder, you
are likely using [`electron-packager`], which includes [`electron-osx-sign`] and
[`electron-notarize`].
If you're using Packager's API, you can pass [in configuration that both signs
description: 'To distribute your app with Electron, you need to package and rebrand it. To do this, you can either use specialized tooling or manual approaches.'
slug: distribution-overview
hide_title: false
---
Once your app is ready for production, there are a couple steps you need to take before
you can deliver it to your users.
## Packaging
To distribute your app with Electron, you need to package all your resources and assets
into an executable and rebrand it. To do this, you can either use specialized tooling
or do it manually. See the [Application Packaging][application-packaging] tutorial
for more information.
## Code signing
Code signing is a security technology that you use to certify that an app was
created by you. You should sign your application so it does not trigger the
security checks of your user's operating system.
To get started with each operating system's code signing process, please read the
[Code Signing][code-signing] docs.
## Publishing
Once your app is packaged and signed, you can freely distribute your app directly
to users by uploading your installers online.
To reach more users, you can also choose to upload your app to each operating system's
digital distribution platform (i.e. app store). These require another build step aside
from your direct download app. For more information, check out each individual app store guide:
- [Mac App Store][mac-app]
- [Windows Store][windows-store]
- [Snapcraft (Linux)][snapcraft]
## Updating
Electron's auto-updater allows you to deliver application updates to users
without forcing them to manually download new versions of your application.
Check out the [Updating Applications][updates] guide for details on implementing automatic updates
* The `-alpha.1`, `-beta.1`, and `stable` dates are our solid release dates.
* We strive for weekly alpha/beta releases, but we often release more than scheduled.
* All dates are our goals but there may be reasons for adjusting the stable deadline, such as security bugs.
* Take a look at the [5.0.0 Timeline blog post](https://electronjs.org/blog/electron-5-0-timeline) for info about publicizing our release dates.
* Since Electron 6.0, we've been targeting every other Chromium version and releasing our stable on the same day as Chrome stable. You can reference Chromium's release schedule [here](https://chromiumdash.appspot.com/schedule). See [Electron's new release cadence blog post](https://www.electronjs.org/blog/12-week-cadence) for more details on our release schedule.
* Starting in Electron 16.0, we will release on an 8-week cadence. See [Electron's new 8-week cadence blog post](https://www.electronjs.org/blog/8-week-cadence) for more details.
* Since Electron 5, Electron has been publicizing its release dates ([see blog post](https://electronjs.org/blog/electron-5-0-timeline)).
* Since Electron 6, Electron major versions have been targeting every other Chromium major version. Each Electron stable should happen on the same day as Chrome stable ([see blog post](https://www.electronjs.org/blog/12-week-cadence)).
* Since Electron 16, Electron has been releasing major versions on an 8-week cadence in accordance to Chrome's change to a 4-week release cadence ([see blog post](https://www.electronjs.org/blog/8-week-cadence)).
:::info Chrome release dates
Chromium has the own public release schedule [here](https://chromiumdash.appspot.com/schedule).
:::
## Version support policy
:::info
Beginning in September 2021 (Electron 15), the Electron team
will temporarily support the latest **four** stable major versions. This
extended support is intended to help Electron developers transition to
the [new 8-week release cadence](https://electronjs.org/blog/8-week-cadence),
and will continue until the release of Electron 19. At that time,
the Electron team will drop support back to the latest three stable major versions.
:::
The latest three *stable* major versions are supported by the Electron team.
For example, if the latest release is 6.1.x, then the 5.0.x as well
as the 4.2.x series are supported. We only support the latest minor release
for each stable release series. This means that in the case of a security fix,
6.1.x will receive the fix, but we will not release a new version of 6.0.x.
The latest stable release unilaterally receives all fixes from `main`,
and the version prior to that receives the vast majority of those fixes
as time and bandwidth warrants. The oldest supported release line will receive
only security fixes directly.
### Breaking API changes
When an API is changed or removed in a way that breaks existing functionality, the
previous functionality will be supported for a minimum of two major versions when
possible before being removed. For example, if a function takes three arguments,
and that number is reduced to two in major version 10, the three-argument version would
continue to work until, at minimum, major version 12. Past the minimum two-version
threshold, we will attempt to support backwards compatibility beyond two versions
until the maintainers feel the maintenance burden is too high to continue doing so.
### End-of-life
When a release branch reaches the end of its support cycle, the series
will be deprecated in NPM and a final end-of-support release will be
made. This release will add a warning to inform that an unsupported
version of Electron is in use.
These steps are to help app developers learn when a branch they're
using becomes unsupported, but without being excessively intrusive
to end users.
If an application has exceptional circumstances and needs to stay
on an unsupported series of Electron, developers can silence the
end-of-support warning by omitting the final release from the app's
`package.json``devDependencies`. For example, since the 1-6-x series
ended with an end-of-support 1.6.18 release, developers could choose
to stay in the 1-6-x series without warnings with `devDependency` of
@@ -48,7 +48,7 @@ Stabilization branches are branches that run parallel to `main`, taking in only
Since Electron 8, stabilization branches are always **major** version lines, and named against the following template `$MAJOR-x-y` e.g. `8-x-y`. Prior to that we used **minor** version lines and named them as `$MAJOR-$MINOR-x` e.g. `2-0-x`.
We allow for multiple stabilization branches to exist simultaneously, one for each supported version. For more details on which versions are supported, see our [Electron Release Timelines](./electron-timelines.md) doc.
We allow for multiple stabilization branches to exist simultaneously, one for each supported version. For more details on which versions are supported, see our [Electron Releases](./electron-timelines.md) doc.
@@ -107,6 +107,15 @@ A few examples of how various SemVer ranges will pick up new releases:

### Backport request process
All supported release lines will accept external pull requests to backport
fixes previously merged to `main`, though this may be on a case-by-case
basis for some older supported lines. All contested decisions around release
line backports will be resolved by the
[Releases Working Group](https://github.com/electron/governance/tree/main/wg-releases)
as an agenda item at their weekly meeting the week the backport PR is raised.
## Feature flags
Feature flags are a common practice in Chromium, and are well-established in the web-development ecosystem. In the context of Electron, a feature flag or **soft branch** must have the following properties:
description: 'Welcome to the Electron documentation! If this is your first time developing an Electron app, read through this Getting Started section to get familiar with the basics. Otherwise, feel free to explore our guides and API documentation!'
slug: /latest/
hide_title: false
---
Welcome to the Electron documentation! If this is your first time developing
an Electron app, read through this Getting Started section to get familiar with the
basics. Otherwise, feel free to explore our guides and API documentation!
## What is Electron?
# What is Electron?
Electron is a framework for building desktop applications using JavaScript,
HTML, and CSS. By embedding [Chromium][chromium] and [Node.js][node] into its
@@ -12,20 +13,12 @@ binary, Electron allows you to maintain one JavaScript codebase and create
cross-platform apps that work on Windows, macOS, and Linux — no native development
experience required.
## Prerequisites
## Getting started
These docs operate under the assumption that the reader is familiar with both
Node.js and general web development. If you need to get more comfortable with
either of these areas, we recommend the following resources:
* [Getting started with the Web (MDN)][mdn-guide]
* [Introduction to Node.js][node-guide]
Moreover, you'll have a better time understanding how Electron works if you get
acquainted with Chromium's process model. You can get a brief overview of
Chrome architecture with the [Chrome comic][comic], which was released alongside
Chrome's launch back in 2008. Although it's been over a decade since then, the
core principles introduced in the comic remain helpful to understand Electron.
We recommend you to start with the [tutorial], which guides you through the
process of developing an Electron app and distributing it to users.
The [examples] and [API documentation] are also good places to browse around
and discover new things.
## Running examples with Electron Fiddle
@@ -39,21 +32,44 @@ a code block. If you have Fiddle installed, this button will open a
`fiddle.electronjs.org` link that will automatically load the example into Fiddle,
no copy-pasting required.
```fiddle docs/fiddles/quick-start
```
## What is in the docs?
All the official documentation is available from the sidebar. These
are the different categories and what you can expect on each one:
- **Tutorial**: An end-to-end guide on how to create and publish your first Electron
application.
- **Processes in Electron**: In-depth reference on Electron processes and how to work with them.
- **Best Practices**: Important checklists to keep in mind when developing an Electron app.
- **How-To Examples**: Quick references to add features to your Electron app.
- **Development**: Miscellaneous development guides.
- **Distribution**: Learn how to distribute your app to end users.
- **Testing and debugging**: How to debug JavaScript, write tests, and other tools used
to create quality Electron applications.
- **Resources**: Useful links to better understand how the Electron project works
and is organized.
- **Contributing to Electron**: Compiling Electron and making contributions can be daunting.
We try to make it easier in this section.
## Getting help
Are you getting stuck anywhere? Here are a few links to places to look:
* If you need help with developing your app, our [community Discord server][discord]
is a great place to get advice from other Electron app developers.
* If you suspect you're running into a bug with the `electron` package, please check
the [GitHub issue tracker][issue-tracker] to see if any existing issues match your
problem. If not, feel free to fill out our bug report template and submit a new issue.
- If you need help with developing your app, our [community Discord server][discord]
is a great place to get advice from other Electron app developers.
- If you suspect you're running into a bug with the `electron` package, please check
the [GitHub issue tracker][issue-tracker] to see if any existing issues match your
problem. If not, feel free to fill out our bug report template and submit a new issue.
description: 'Electron inherits its multi-process architecture from Chromium, which makes the framework architecturally very similar to a modern web browser. This guide will expand on the concepts applied in the tutorial.'
slug: process-model
hide_title: false
---
# Process Model
Electron inherits its multi-process architecture from Chromium, which makes the framework
architecturally very similar to a modern web browser. In this guide, we'll expound on
the conceptual knowledge of Electron that we applied in the minimal [quick start app][].
architecturally very similar to a modern web browser. This guide will expand on the
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.