fix: drag and drop should copy on macOS (#35963)
Co-authored-by: Shelley Vohr <shelley.vohr@gmail.com>
Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com>
Co-authored-by: Shelley Vohr <shelley.vohr@gmail.com>
fix: set display_id in desktop capturer on Linux (#33861)
Previously, display_id was an empty string, pending Chrome support for
sharing individual screens. Now that this has been added, it is
desirable to have this property set correctly.
Co-authored-by: John Kleinschmidt <jkleinsc@electronjs.org>
Co-authored-by: James Cash <james.nvc@gmail.com>
Co-authored-by: John Kleinschmidt <jkleinsc@electronjs.org>
fix: Handle an electron.d.ts file in a custom build (#33979)
* Handle an electron.d.ts file in a custom build
* Fix linter issues
Co-authored-by: Felix Rieseberg <felixr@stripe.com>
Co-authored-by: Felix Rieseberg <felix@felixrieseberg.com>
Co-authored-by: Felix Rieseberg <felixr@stripe.com>
* fix: set macOS crypto keychain name earlier
* spec: ensure arm64 mac tests are cleaned up
Co-authored-by: Samuel Attard <sattard@salesforce.com>
Co-authored-by: Samuel Attard <samuel.r.attard@gmail.com>
* docs: changed event.data to data under the message.port in docs
* docs: corrected BrowserWindow wrong usage and change window.messagePort to window.electronMessagePort
Co-authored-by: cyrilchukwuebuka <muofunanya3@gmail.com>
feat: allow custom v8 snapshots to be used in the main process and the default snapshot in the renderer process (#35266)
* Updates to allow for using a custom v8 snapshot file name
* Allow using a custom v8 snapshot file name
* Fix up patch due to merge
* Use fuse to set up custom v8 snapshot file in browser process
* Refactor to use delegate instead of command line parameter
* Refactoring
* Update due to merge
* PR comments
* Rename patch
* Rename patch
chore: update patches
Co-authored-by: Ryan Manuel <ryanm@cypress.io>
docs: fix wording mistake in security.md section 4 (#35682)
Update security.md
Under "4. Process Sandboxing", it said "For mor information on what `contextIsolation` is..." which was the previous section (copied from there). This updates it to say "For more information on what Process Sandboxing is..."
Co-authored-by: Sebastian Vittersø <37065184+sebastianvitterso@users.noreply.github.com>
Right now the `check-symlinks.js` assumes that the branding product name
is "Electron". If users change `BRANDING.json` on custom builds, the
script will fail.
Signed-off-by: Juan Cruz Viotti <jv@jviotti.com>
Signed-off-by: Juan Cruz Viotti <jv@jviotti.com>
Co-authored-by: Juan Cruz Viotti <jv@jviotti.com>
* Use absolute URL in faq.md image link
The relative link is rendered relative to the host domain, which works fine when viewing it on Github, but since you also use the same generated HTML in your doc site, the link is broken. See here: https://www.electronjs.org/docs/latest/faq#the-font-looks-blurry-what-is-this-and-what-can-i-do
Using an absolute URL here should fix the issue on the main site.
* Use inline image reference for subpixel rendering example
As suggested by @dsanders11
Co-authored-by: Adrian Petrescu <adrian@apetre.sc>
fix: session.getBlobData never resolves with blob sizes > 65536 (#35277)
* fix: session.getBlobData never resolves with blob sizes > 65536 (#34398)
* Add unit test case for session.getBlobData
Co-authored-by: John Kleinschmidt <jkleinsc@electronjs.org>
Co-authored-by: Frank Pian <bianyongfang@vip.qq.com>
Co-authored-by: John Kleinschmidt <jkleinsc@electronjs.org>
* fix: ensure chrome colors are initialized
* build: fix linking on windows
* build: fix linking on windows
* build: add needed files to chromium_src/BUILD
Co-authored-by: Samuel Attard <sattard@salesforce.com>
Co-authored-by: VerteDinde <keeleymhammond@gmail.com>
* docs: add Electron deps to license credits file
* fixup! docs: add Electron deps to license credits file
remove nan; it is dev-only
Co-authored-by: Charles Kerr <charles@charleskerr.com>
Co-authored-by: John Kleinschmidt <jkleinsc@electronjs.org>
* Remove unused import of path
This import gives out the error in the preload script:
Error: module not found: path
at preloadRequire
* Remove import path as it is not used in the script
note: Removes import path as it is not used in the script
Co-authored-by: Rhitik Bhatt <bhattrhitik95@gmail.com>
test: temporarily disable tests on mas arm64 that are causing a crash (#35226)
* test: temporarily disable test on mas arm64 that is causing crash
* disable the right test
* chore: speculative fix for CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER crash
* enable all the tests
* Revert "chore: speculative fix for CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER crash"
This reverts commit b7c8ef364c.
* test: disable tests that crash on mas arm64
Co-authored-by: John Kleinschmidt <jkleinsc@electronjs.org>
* fix: broken wayland window decorations due to botched chromium update
The `GetTitlebarBounds().height()` is obviously intended to be placed in
the `top` parameter, which used to be the second one before upstream
removed multi-parameter `gfx::Rect::Inset`, but it's the first parameter
for `gfx::Insets::TLBR`, which was intended to replace the removed
`Inset` function. However, whoever updated Chromium kept the parameter
unchanged, causing the title bar height to be passed to the `left`
parameter, causing the window title bar to be unclickable.
* fix: wayland window top bar buttons unclickable
Use NonClientFrameView::TargetForRect for the ClientFrameViewLinux
implementation because the default inherited from FramelessView blocks
any non-HTCLIENT events.
* fix: add maximized parameter to LinuxUI::GetWindowFrameProvider
* fix: pass frame_->IsMaximized() to GetWindowFrameProvider
This ensures that the toolkit renders the window decorations in maximized mode
while the window is maximized to ensure that there is no empty space around the window.
This page describes each of the categories available in the sidebar, but some of the category titles didn't match.
Co-authored-by: Maya Nedeljković Batić <maya.nedeljko@gmail.com>
* fix: modify file extension generation on Windows
* modify includes
* include vector in header
* add win build flags
* remove hardcoded strings
* Update shell/browser/electron_download_manager_delegate.h
Co-authored-by: Charles Kerr <charles@charleskerr.com>
* fix string manipulation and function definitions
* Update electron_download_manager_delegate.h
* convert to std::string and modify for electron
* Update shell/browser/electron_download_manager_delegate.cc
Co-authored-by: Charles Kerr <charles@charleskerr.com>
* remove vector include and update conversion
* add vectr include for lint
Co-authored-by: mlaurencin <mlaurencin@electronjs.org>
Co-authored-by: Michaela Laurencin <35157522+mlaurencin@users.noreply.github.com>
Co-authored-by: Charles Kerr <charles@charleskerr.com>
* fix: touch events not recognized by WCO on windows
* chore: update patches
Co-authored-by: deepak1556 <hop2deep@gmail.com>
Co-authored-by: PatchUp <73610968+patchup[bot]@users.noreply.github.com>
* fix: ensure native modules are built with config.gypi
This works by patching node.h to check that two defines are set using the equivilant of an XNOR operation. One define "ELECTRON_ENSURE_CONFIG_GYPI" is set via common.gypi which is _already_ used to build native modules and has been since the dawn of time. Therefore this define will be set for all native module compilations targetting the Electron runtime. The second define "USING_ELECTRON_CONFIG_GYPI" is only defined when the gypi argument "using_electron_config_gypi" is set to 1 which is only done so via config.gypi. Only new enough versions of node-gyp correctly use the config.gypi file thus resulting in a compilation error on version of node-gyp that are too old.
* chore: fix lint
* chore: update patches
Co-authored-by: Samuel Attard <sattard@salesforce.com>
Co-authored-by: VerteDinde <vertedinde@electronjs.org>
Co-authored-by: PatchUp <73610968+patchup[bot]@users.noreply.github.com>
* fix: remove skip-taskbar feature on Linux.
Marked as unsupported in e19, now removed in e20.
See #33226 for more information
* docs: remove skipTaskbar note in browserWindow
Co-authored-by: Charles Kerr <charles@charleskerr.com>
Co-authored-by: Keeley Hammond <khammond@slack-corp.com>
* docs: new main -> renderers messageChannel example
* consistent use of your
* fix a typo
* linting
* markdown linting
* Update docs/tutorial/message-ports.md
Co-authored-by: Erick Zhao <erick@hotmail.ca>
* update code example headings, reference contextIsolation example
* remove nodeIntegration: false from browserWindows
* rename "messagePort" to "electronMessagePort" for compatibility
Co-authored-by: Kilian Valkhof <kilian@kilianvalkhof.com>
Co-authored-by: Erick Zhao <erick@hotmail.ca>
ci: switch to GHA for WOA (#35109)
* ci: switch to GHA for WOA
Co-authored-by: Shelley Vohr <shelley.vohr@gmail.com>
(cherry picked from commit 674596d11e)
* chore: bump chromium in DEPS to 104.0.5112.65
* chore: update patches
* test: remove duplicate test that is causing hang in Windows (#35071)
(cherry picked from commit 182ab9ad76)
Co-authored-by: electron-roller[bot] <84116207+electron-roller[bot]@users.noreply.github.com>
Co-authored-by: PatchUp <73610968+patchup[bot]@users.noreply.github.com>
Co-authored-by: John Kleinschmidt <jkleinsc@electronjs.org>
ElectronCrashReporterClient::GetProcessSimpleAnnotations() merges
annotations provided as argument with global_annotations_,
preserving useful information.
Co-authored-by: Alexander Petrov <zowers+github@zowers.net>
fix: do not define _LIBCPP_ABI_NAMESPACE=Cr for all native modules (#34932)
This define is only needed when linking against Chromiums libc++ which we currently
do not ship / expose the symbols of. We probably should make those symbols visible and
actually ensure that electron-rebuild et. al link against our libc++ instead of the system libc++
but for now this fixes compilation issues on macOS where the default system clang links to the system libc++
which does not (obviously) use the Chromium ABI namespace.
For our nan tests which do link against Chromiums libc++ we define the ABI namespace in the spec runner.
Co-authored-by: Samuel Attard <sam@electronjs.org>
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>
* build: test disabling security
* build: install python2 during tests
* build: do not install python2 on arm64 runners
* attempt 2
* build: only allow 13.3.0 xcode
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>
* Trigger Build
Co-authored-by: Darshan Sen <raisinten@gmail.com>
Co-authored-by: John Kleinschmidt <jkleinsc@electronjs.org>
* refactor: use stubs for gdk-pixbuf dependency
* Adjust build file
* Add includes
* Merge gdk_pixbuf stubs into gtk stubs
* Split pixbuf sigs into own file again
* Add initialization check
* Apply PR feedback
Co-authored-by: Raymond Zhao <raymondzhao@microsoft.com>
Co-authored-by: Raymond Zhao <7199958+rzhao271@users.noreply.github.com>
feat: add immersive dark mode on windows (#33624)
* feat: add immersive dark mode
* fix syntax and add header
* add me
* Update fuses.json5
* fix: redraw title bar on dark mode change
* chore: SetWindowTheme doesn't seem to be needed
* chore: separate out Win 10 dark mode implementation
* final touches
* final touches
* chore: limit Win 10 to >= 20H1 and drop fuse
* fix types
* fix lint
Co-authored-by: Micha Hanselmann <micha.hanselmann@gmail.com>
Co-authored-by: David Sanders <dsanders11@ucsbalum.com>
Co-authored-by: Michaela Laurencin <35157522+mlaurencin@users.noreply.github.com>
Co-authored-by: Micha Hanselmann <micha.hanselmann@gmail.com>
Co-authored-by: David Sanders <dsanders11@ucsbalum.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
Co-authored-by: John Kleinschmidt <jkleinsc@electronjs.org>
Co-authored-by: Samuel Attard <sattard@salesforce.com>
* feat: add support for HIDDevice.forget()
* chore: remove whitespace
* chore: use `SetGetter` to serialize the render_frame_host
Co-authored-by: Samuel Maddock <samuel.maddock@gmail.com>
* fixup chore: use `SetGetter` to serialize the render_frame_host
* fixup after rebase
* fixup for crash on navigator.serial.getPorts()
* fixup for lint
Co-authored-by: Samuel Maddock <samuel.maddock@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>
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
* fix: create singleton pipename from user & executable
* fix: use process id & main thread id for pipe name
* fix: write rand to file using WIN method
* fix: remove file rand, add user_name to pipe
* chore: style fixes, shorten program_name & user_name
* fix: remove user_name
* feat: redirect Electron/Chromium cache location
* fix: network services should also use browserData
* test: browserData
* chore: no need to explicitly create dir
* feat: browserData => sessionData
* test: check existings of specific items
* docs: add background on userData and sessionData
Co-authored-by: emmanuel.kimmerlin@thomsonreuters.com <emmanuel.kimmerlin@thomsonreuters.com>
* test: unflake webview fullscreen test
* test: unflake net throttle test
* Update spec-main/api-net-spec.ts
Co-authored-by: Jeremy Rose <jeremya@chromium.org>
Co-authored-by: Jeremy Rose <jeremya@chromium.org>
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>
* 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
* test: use custom userData folder for requestSingleInstanceLock()
* update test
* prefix test folder path
* fix: create userDataDir on requestSingleInstanceLock() if needed
* Trigger Build
* 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>
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?
"Chromium has updated the mac_deployment_target, please update this assert, update the supported versions documentation (docs/tutorial/support.md) and flag this as a breaking change")
}
@@ -79,6 +79,13 @@ if (is_linux) {
]
}
# Generates electron_gtk_stubs.h header which contains
# stubs for extracting function ptrs from the gtk library.
# Function signatures for which stubs are required should be
# declared in electron_gtk.sigs, currently this file contains
# signatures for the functions used with native file chooser
# implementation. In future, this file can be extended to contain
Each Electron release provides binaries for macOS, Windows, and Linux.
* macOS (High Sierra 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).
@@ -582,6 +582,10 @@ You should seek to use the `steal` option as sparingly as possible.
Hides all application windows without minimizing them.
### `app.isHidden()` _macOS_
Returns `boolean` - `true` if the application—including all of its windows—is hidden (e.g. with `Command-H`), `false` otherwise.
### `app.show()` _macOS_
Shows application windows after they were hidden. Does not automatically focus
@@ -607,9 +611,18 @@ Returns `string` - The current application directory.
*`%APPDATA%` on Windows
*`$XDG_CONFIG_HOME` or `~/.config` on Linux
*`~/Library/Application Support` on macOS
*`userData` The directory for storing your app's configuration files, which by
default it is the `appData` directory appended with your app's name.
*`cache`
*`userData` The directory for storing your app's configuration files, which
by default is the `appData` directory appended with your app's name. By
convention files storing user data should be written to this directory, and
it is not recommended to write large files here because some environments
may backup this directory to cloud storage.
*`sessionData` The directory for storing data generated by `Session`, such
as localStorage, cookies, disk cache, downloaded dictionaries, network
state, devtools files. By default this points to `userData`. Chromium may
write very large disk cache here, so if your app does not rely on browser
storage like localStorage or cookies to save user data, it is recommended
to set this directory to other locations to avoid polluting the `userData`
directory.
*`temp` Temporary directory.
*`exe` The current executable file.
*`module` The `libchromiumcontent` library.
@@ -659,9 +672,9 @@ In that case, the directory should be created with `fs.mkdirSync` or similar.
You can only override paths of a `name` defined in `app.getPath`.
By default, web pages' cookies and caches will be stored under the `userData`
By default, web pages' cookies and caches will be stored under the `sessionData`
directory. If you want to change this location, you have to override the
`userData` path before the `ready` event of the `app` module is emitted.
`sessionData` path before the `ready` event of the `app` module is emitted.
### `app.getVersion()`
@@ -690,7 +703,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).
@@ -1059,7 +1072,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).
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:
@@ -158,20 +161,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
@@ -185,9 +188,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
@@ -201,27 +205,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`.
*`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.
@@ -229,36 +236,42 @@ 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 full screen 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.
@@ -310,8 +323,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`.
Emitted when a new HID device becomes available. For example, when a new USB device is plugged in.
This event will only be emitted after `navigator.hid.requestDevice` has been called and `select-hid-device` has fired.
Emitted after `navigator.hid.requestDevice` has been called and
`select-hid-device` has fired if a new device becomes available before
the callback from `select-hid-device` is called. This event is intended for
use when using a UI to ask users to pick a device so that the UI can be updated
with the newly added device.
#### Event: 'hid-device-removed'
@@ -266,9 +268,24 @@ Returns:
*`device` [HIDDevice[]](structures/hid-device.md)
*`frame` [WebFrameMain](web-frame-main.md)
Emitted when a HID device has been removed. For example, this event will fire when a USB device is unplugged.
Emitted after `navigator.hid.requestDevice` has been called and
`select-hid-device` has fired if a device has been removed before the callback
from `select-hid-device` is called. This event is intended for use when using
a UI to ask users to pick a device so that the UI can be updated to remove the
specified device.
This event will only be emitted after `navigator.hid.requestDevice` has been called and `select-hid-device` has fired.
#### Event: 'hid-device-revoked'
Returns:
*`event` Event
*`details` Object
*`device` [HIDDevice[]](structures/hid-device.md)
*`origin` string (optional) - The origin that the device has been revoked from.
Emitted after `HIDDevice.forget()` has been called. This event can be used
to help maintain persistent storage of permissions when
`setDevicePermissionHandler` is used.
#### Event: 'select-serial-port'
@@ -348,7 +365,11 @@ Returns:
*`port` [SerialPort](structures/serial-port.md)
*`webContents` [WebContents](web-contents.md)
Emitted after `navigator.serial.requestPort` has been called and`select-serial-port` has fired if a new serial port becomes available. For example, this event will fire when a new USB device is plugged in.
Emitted after `navigator.serial.requestPort` has been called and
`select-serial-port` has fired if a new serial port becomes available before
the callback from `select-serial-port` is called. This event is intended for
use when using a UI to ask users to pick a port so that the UI can be updated
with the newly added port.
#### Event: 'serial-port-removed'
@@ -358,7 +379,11 @@ Returns:
*`port` [SerialPort](structures/serial-port.md)
*`webContents` [WebContents](web-contents.md)
Emitted after `navigator.serial.requestPort` has been called and`select-serial-port` has fired if a serial port has been removed. For example, this event will fire when a USB device is unplugged.
Emitted after `navigator.serial.requestPort` has been called and
`select-serial-port` has fired if a serial port has been removed before the
callback from `select-serial-port` is called. This event is intended for use
when using a UI to ask users to pick a port so that the UI can be updated
to remove the specified port.
### Instance Methods
@@ -567,7 +592,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.
*`notifications` - Request notification creation and the ability to display them in the user's system tray.
*`midi` - Request MIDI access in the `webmidi` API.
*`midiSysex` - Request the use of system exclusive messages in the `webmidi` API.
*`pointerLock` - Request to directly interpret mouse movements as an input method. Click [here](https://developer.mozilla.org/en-US/docs/Web/API/Pointer_Lock_API) to know more.
*`pointerLock` - Request to directly interpret mouse movements as an input method. Click [here](https://developer.mozilla.org/en-US/docs/Web/API/Pointer_Lock_API) to know more. These requests always appear to originate from the main frame.
*`fullscreen` - Request for the app to enter fullscreen mode.
*`openExternal` - Request to open links in external applications.
If you want to keep exact same behaviors on all platforms, you should not
rely on the `click` event; instead, always attach a context menu to the tray icon.
__Linux__
* On Linux the app indicator will be used if it is supported, otherwise
`GtkStatusIcon` will be used instead.
* On Linux distributions that only have app indicator support, you have to
install `libappindicator1` to make the tray icon work.
* The app indicator will be used if it is supported, otherwise
`GtkStatusIcon` will be used instead.
* App indicator will only be shown when it has a context menu.
*When app indicator is used on Linux, the `click` event is ignored.
*On Linux in order for changes made to individual `MenuItem`s to take effect,
*The `click` event is ignored when using the app indicator.
*In order for changes made to individual `MenuItem`s to take effect,
you have to call `setContextMenu` again. For example:
```javascript
@@ -55,10 +60,16 @@ app.whenReady().then(() => {
})
```
* On Windows it is recommended to use `ICO` icons to get best visual effects.
__MacOS__
If you want to keep exact same behaviors on all platforms, you should not
rely on the `click` event and always attach a context menu to the tray icon.
* Icons passed to the Tray constructor should be [Template Images](native-image.md#template-image).
* To make sure your icon isn't grainy on retina monitors, be sure your `@2x` image is 144dpi.
* If you are bundling your application (e.g., with webpack for development), be sure that the file names are not being mangled or hashed. The filename needs to end in Template, and the `@2x` image needs to have the same filename as the standard image, or MacOS will not magically invert your image's colors or use the high density image.
* 16x16 (72dpi) and 32x32@2x (144dpi) work well for most icons.
__Windows__
* It is recommended to use `ICO` icons to get best visual effects.
@@ -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'
@@ -820,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.
@@ -34,9 +34,19 @@ 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.
### API Changed: `session.setDevicePermissionHandler(handler)`
The handler invoked when `session.setDevicePermissionHandler(handler)` is used
has a change to its arguments. This handler no longer is passed a frame
`[WebFrameMain](api/web-frame-main.md)`, but instead is passed the `origin`, which
is the origin that is checking for device permission.
## Planned Breaking API Changes (19.0)
*None (yet)*
### 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)
@@ -372,7 +382,7 @@ value.
In Electron 12, `contextIsolation` will be enabled by default. To restore
the previous behavior, `contextIsolation: false` must be specified in WebPreferences.
We [recommend having contextIsolation enabled](tutorial/security.md#3-enable-context-isolation-for-remote-content) for the security of your application.
We [recommend having contextIsolation enabled](tutorial/security.md#3-enable-context-isolation) for the security of your application.
Another implication is that `require()` cannot be used in the renderer process unless
`nodeIntegration` is `true` and `contextIsolation` is `false`.
@@ -1203,6 +1213,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.
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`.
@@ -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
Sub-pixel anti-aliasing needs a non-transparent background of the layer containing the font glyphs. (See [this issue](https://github.com/electron/electron/issues/6344#issuecomment-420371918) for more info).
@@ -161,4 +161,3 @@ Notice that just setting the background in the CSS does not have the desired eff
<i>Supports: Win, macOS, Linux <span>|</span> Process: Both</i>
<div>
<div>
<buttonid="async-msg">Ping</button>
<spanid="async-reply"></span>
</div>
<p>Using <code>ipc</code> to send messages between processes asynchronously is the preferred method since it will return when finished without blocking other operations in the same process.</p>
<p>This example sends a "ping" from this process (renderer) to the main process. The main process then replies with "pong".</p>
</div>
</div>
</div>
<script>
// You can also require other files to run in this process
<i>Supports: Win, macOS, Linux <span>|</span> Process: Both</i>
<div>
<div>
<buttonid="sync-msg">Ping</button>
<spanid="sync-reply"></span>
</div>
<p>You can use the <code>ipc</code> module to send synchronous messages between processes as well, but note that the synchronous nature of this method means that it <b>will block</b> other operations while completing its task.</p>
<p>This example sends a synchronous message, "ping", from this process (renderer) to the main process. The main process then replies with "pong".</p>
</div>
</div>
</div>
<script>
// You can also require other files to run in this process
description: 'An experimental feature that ensures the validity of ASAR contents at runtime.'
slug: asar-integrity
hide_title: false
---
## Platform Support
Currently ASAR integrity checking is only supported on macOS.
## Requirements
### Electron Forge / Electron Packager
If you are using `>= electron-packager@15.4.0` or `>= @electron-forge/core@6.0.0-beta.61` then all these requirements are met for you automatically and you can skip to [Toggling the Fuse](#toggling-the-fuse).
### Other build systems
In order to enable ASAR integrity checking you need to ensure that your `app.asar` file was generated by a version of the `asar` npm package that supports asar integrity. Support was introduced in version `3.1.0`.
Your must then populate a valid `ElectronAsarIntegrity` dictionary block in your packaged apps `Info.plist`. An example is included below.
Valid `algorithm` values are currently `SHA256` only. The `hash` is a hash of the ASAR header using the given algorithm. The `asar` package exposes a `getRawHeader` method whose result can then be hashed to generate this value.
## Toggling the Fuse
ASAR integrity checking is currently disabled by default and can be enabled by toggling a fuse. See [Electron Fuses](fuses.md) for more information on what Electron Fuses are and how they work. When enabling this fuse you typically also want to enable the `onlyLoadAppFromAsar` fuse otherwise the validity checking can be bypassed via the Electron app code search path.
@@ -26,10 +26,8 @@ beginners, using a command line tool is likely to be helpful*.
## electron-forge
A "complete tool for building modern Electron applications". Electron Forge
unifies the existing (and well maintained) build tools for Electron development
into a cohesive package so that anyone can jump right in to Electron
development.
Electron Forge is a tool for packaging and publishing Electron applications. It unifies Electron's tooling ecosystem
into a single extensible interface so that anyone can jump right into making Electron apps.
Forge comes with [a ready-to-use template](https://electronforge.io/templates) using Webpack as a bundler. It includes an example typescript configuration and provides two configuration files to enable easy customization. It uses the same core modules used by the
greater Electron community (like [`electron-packager`](https://github.com/electron/electron-packager)) –
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.
### 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).
Detailed instructions on how to configure your application can be found in the [Electron Forge Code Signing Tutorial](https://www.electronforge.io/guides/code-signing/code-signing-macos).
### Using Electron Packager
If you're not using an integrated build pipeline like Forge or Builder, you
If you're not using an integrated build pipeline like Forge, you
are likely using [`electron-packager`], which includes [`electron-osx-sign`] and
[`electron-notarize`].
@@ -204,36 +130,7 @@ commit it to your source code.
### Using Electron Forge
Once you have a code signing certificate file (`.pfx`), you can sign
[Squirrel.Windows][maker-squirrel] and [MSI][maker-msi] installers in Electron Forge
with the `certificateFile` and `certificatePassword` fields in their respective
configuration objects.
For example, if you keep your Forge config in your `package.json` file and are
creating a Squirrel.Windows installer:
```json {9-15} title='package.json'
{
"name": "my-app",
"version": "0.0.1",
//...
"config": {
"forge": {
"packagerConfig": {},
"makers": [
{
"name": "@electron-forge/maker-squirrel",
"config": {
"certificateFile": "./cert.pfx",
"certificatePassword": "this-is-a-secret"
}
}
]
}
}
//...
}
```
Electron Forge is the recommended way to sign your `Squirrel.Windows` and `WiX MSI` installers. Detailed instructions on how to configure your application can be found in the [Electron Forge Code Signing Tutorial](https://www.electronforge.io/guides/code-signing/code-signing-macos).
* 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:
@@ -8,6 +8,59 @@ For a subset of Electron functionality it makes sense to disable certain feature
Fuses are the solution to this problem, at a high level they are "magic bits" in the Electron binary that can be flipped when packaging your Electron app to enable / disable certain features / restrictions. Because they are flipped at package time before you code sign your app the OS becomes responsible for ensuring those bits aren't flipped back via OS level code signing validation (Gatekeeper / App Locker).
## Current Fuses
### `runAsNode`
**Default:** Enabled
**@electron/fuses:** `FuseV1Options.RunAsNode`
The runAsNode fuse toggles whether the `ELECTRON_RUN_AS_NODE` environment variable is respected or not. Please note that if this fuse is disabled then `process.fork` in the main process will not function as expected as it depends on this environment variable to function.
The cookieEncryption fuse toggles whether the cookie store on disk is encrypted using OS level cryptography keys. By default the sqlite database that Chromium uses to store cookies stores the values in plaintext. If you wish to ensure your apps cookies are encrypted in the same way Chrome does then you should enable this fuse. Please note it is a one-way transition, if you enable this fuse existing unencrypted cookies will be encrypted-on-write but if you then disable the fuse again your cookie store will effectively be corrupt and useless. Most apps can safely enable this fuse.
The nodeOptions fuse toggles whether the [`NODE_OPTIONS`](https://nodejs.org/api/cli.html#node_optionsoptions) environment variable is respected or not. This environment variable can be used to pass all kinds of custom options to the Node.js runtime and isn't typically used by apps in production. Most apps can safely disable this fuse.
The nodeCliInspect fuse toggles whether the `--inspect`, `--inspect-brk`, etc. flags are respected or not. When disabled it also ensures that `SIGUSR1` signal does not initialize the main process inspector. Most apps can safely disable this fuse.
The embeddedAsarIntegrityValidation fuse toggles an experimental feature on macOS that validates the content of the `app.asar` file when it is loaded. This feature is designed to have a minimal performance impact but may marginally slow down file reads from inside the `app.asar` archive.
For more information on how to use asar integrity validation please read the [Asar Integrity](asar-integrity.md) documentation.
The onlyLoadAppFromAsar fuse changes the search system that Electron uses to locate your app code. By default Electron will search in the following order `app.asar` -> `app` -> `default_app.asar`. When this fuse is enabled the search order becomes a single entry `app.asar` thus ensuring that when combined with the `embeddedAsarIntegrityValidation` fuse it is impossible to load non-validated code.
The loadBrowserProcessSpecificV8Snapshot fuse changes which V8 snapshot file is used for the browser process. By default Electron's processes will all use the same V8 snapshot file. When this fuse is enabled the browser process uses the file called `browser_v8_context_snapshot.bin` for its V8 snapshot. The other processes will use the V8 snapshot file that they normally do.
@@ -144,7 +144,7 @@ to use `contextIsolation` and set up specific contextBridge calls for each of yo
expected messages, but for the simplicity of this example we don't. You can find an
example of context isolation further down this page at [Communicating directly between the main process and the main world of a context-isolated page](#communicating-directly-between-the-main-process-and-the-main-world-of-a-context-isolated-page)
That means window.messagePort is globally available and you can call
That means window.electronMessagePort is globally available and you can call
`postMessage` on it from anywhere in your app to send a message to the other
is a community-maintained list of useful example apps,
tools and resources.
## Supported Versions
_**Note:** Beginning in September 2021 with 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 eight week release cadence](https://electronjs.org/blog/8-week-cadence), and will continue until May 2022, with
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.
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.
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.
### Currently supported versions
* 18.x.y
* 17.x.y
* 16.x.y
* 15.x.y
### 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
`"electron": 1.6.0 - 1.6.17`.
## Supported Platforms
Following platforms are supported by Electron:
### macOS
Only 64bit binaries are provided for macOS, and the minimum macOS version
supported is macOS 10.11 (El Capitan).
Native support for Apple Silicon (`arm64`) devices was added in Electron 11.0.0.
### Windows
Windows 7 and later are supported, older operating systems are not supported
(and do not work).
Both `ia32` (`x86`) and `x64` (`amd64`) binaries are provided for Windows.
[Native support for Windows on Arm (`arm64`) devices was added in Electron 6.0.8.](windows-arm.md).
Running apps packaged with previous versions is possible using the ia32 binary.
### Linux
The prebuilt binaries of Electron are built on Ubuntu 18.04.
Whether the prebuilt binary can run on a distribution depends on whether the
distribution includes the libraries that Electron is linked to on the building
platform, so only Ubuntu 18.04 is guaranteed to work, but following platforms
are also verified to be able to run the prebuilt binaries of Electron:
* Ubuntu 14.04 and newer
* Fedora 24 and newer
* Debian 8 and newer
* For information on supported releases, see the [Electron Releases](./electron-timelines.md) doc.
* For community support on Electron, see the [Community page](https://www.electronjs.org/community).
* For platform support info, see the [README](https://github.com/electron/electron/blob/main/README.md).
@@ -115,9 +115,9 @@ const win = new BrowserWindow({
})
```
On Windows, you can also specify the color of the overlay and its symbols by setting
`titleBarOverlay` to an object with the `color` and `symbolColor` properties. If an option
is not specified, the color will default to its system color for the window control buttons:
On Windows, you can also specify additional parameters. The color of the overlay and its symbols can be specified by setting `titleBarOverlay` to an object and using the `color` and `symbolColor` properties respectively. The height of the overlay can also be specified with the `height` property.
If a color option is not specified, the color will default to its system color for the window control buttons. Similarly, if the height option is not specified it will default to the default height:
```javascript title='main.js'
// on Windows
@@ -126,7 +126,8 @@ const win = new BrowserWindow({
titleBarStyle: 'hidden',
titleBarOverlay: {
color: '#2f3241',
symbolColor: '#74b1be'
symbolColor: '#74b1be',
height: 60
}
})
```
@@ -135,6 +136,10 @@ const win = new BrowserWindow({
> color and dimension values from a renderer using a set of readonly
> [JavaScript APIs][overlay-javascript-apis] and [CSS Environment Variables][overlay-css-env-vars].
### Limitations
* Transparent colors are currently not supported. Progress updates for this feature can be found in PR [#33567](https://github.com/electron/electron/issues/33567).
## Create transparent windows
By setting the `transparent` option to `true`, you can make a fully transparent window.
<message name="IDS_APP_ACCNAME_CLOSE" desc="The accessible name for the Close button.">
Close
</message>
<message name="IDS_APP_ACCNAME_MINIMIZE" desc="The accessible name for the Minimize button.">
Minimize
</message>
<message name="IDS_APP_ACCNAME_MAXIMIZE" desc="The accessible name for the Maximize button.">
Maximize
</message>
<message name="IDS_APP_ACCNAME_RESTORE" desc="The accessible name for the Restore button.">
Restore
</message>
<!-- Printing Service -->
<message name="IDS_UTILITY_PROCESS_PRINTING_SERVICE_NAME" desc="The name of the utility process used for printing conversions.">
Printing Service
</message>
<message name="IDS_PRINT_INVALID_PRINTER_SETTINGS" desc="Message to display when selected printer is not reachable or its settings are invalid.">
The selected printer is not available or not installed correctly. <ph name="BR"><br></ph> Check your printer or try selecting another printer.
</message>
<message name="IDS_DEFAULT_PRINT_DOCUMENT_TITLE" desc="Default title for a print document">
Untitled Document
</message>
<!-- Desktop Capturer API -->
<message name="IDS_DESKTOP_MEDIA_PICKER_SINGLE_SCREEN_NAME" desc="Name for screens in the desktop media picker UI when there is only one monitor.">
Entire Screen
</message>
<message name="IDS_DESKTOP_MEDIA_PICKER_MULTIPLE_SCREEN_NAME" desc="Name for screens in the desktop media picker UI when there are multiple monitors.">
<message name="IDS_IMAGE_FILES" desc="The description of the image file extensions in the select file dialog.">
Image Files
</message>
<message name="IDS_AUDIO_FILES" desc="The description of the audio file extensions in the select file dialog.">
Audio Files
</message>
<message name="IDS_VIDEO_FILES" desc="The description of the video file extensions in the select file dialog.">
Video Files
</message>
<message name="IDS_CUSTOM_FILES" desc="The description of the custom file extensions in the select file dialog.">
Custom Files
</message>
<message name="IDS_DEFAULT_DOWNLOAD_FILENAME" desc="Default name for downloaded files when we have no idea what they could be.">
download
</message>
<!-- Picture-in-Picture -->
<if expr="is_macosx">
<message name="IDS_PICTURE_IN_PICTURE_TITLE_TEXT" desc="Title of the Picture-in-Picture window. This appears in the system tray and window header.">
Picture in Picture
</message>
</if>
<if expr="not is_macosx">
<message name="IDS_PICTURE_IN_PICTURE_TITLE_TEXT" desc="Title of the Picture-in-Picture window. This appears in the system tray and window header.">
Picture in picture
</message>
</if>
<message name="IDS_PICTURE_IN_PICTURE_PAUSE_CONTROL_TEXT" desc="Text label of the pause control button. The button appears when the user hovers over the Picture-in-Picture window and the video is currently playing.">
Pause
</message>
<message name="IDS_PICTURE_IN_PICTURE_PLAY_CONTROL_TEXT" desc="Text label of the play control button. The button appears when the user hovers over the Picture-in-Picture window and the video is currently paused.">
Play
</message>
<message name="IDS_PICTURE_IN_PICTURE_REPLAY_CONTROL_TEXT" desc="Text label of the replay control button. The button appears when the user hovers over the Picture-in-Picture window and the video is ended.">
Play from the beginning
</message>
<message name="IDS_PICTURE_IN_PICTURE_BACK_TO_TAB_CONTROL_TEXT" desc="Text label of the back to tab control button. The button appears when the user hovers over the Picture-in-Picture window.">
Back to video player
</message>
<message name="IDS_PICTURE_IN_PICTURE_MUTE_CONTROL_TEXT" desc="Text label of the mute control button. The button appears when the user hovers over the Picture-in-Picture window and the video is currently unmuted.">
Mute
</message>
<message name="IDS_PICTURE_IN_PICTURE_UNMUTE_CONTROL_TEXT" desc="Text label of the mute control button. The button appears when the user hovers over the Picture-in-Picture window and the video is currently muted.">
Unmute
</message>
<message name="IDS_PICTURE_IN_PICTURE_SKIP_AD_CONTROL_TEXT" desc="Text label of the skip ad control button. The button appears when the user hovers over the Picture-in-Picture window.">
Skip Ad
</message>
<message name="IDS_PICTURE_IN_PICTURE_MUTE_MICROPHONE_TEXT" desc="Text label of the mute microphone control button. The button appears when the user hovers over the Picture-in-Picture window.">
Mute microphone
</message>
<message name="IDS_PICTURE_IN_PICTURE_UNMUTE_MICROPHONE_TEXT" desc="Text label of the unmute microphone control button. The button appears when the user hovers over the Picture-in-Picture window.">
Unmute microphone
</message>
<message name="IDS_PICTURE_IN_PICTURE_TURN_ON_CAMERA_TEXT" desc="Text label of the turn on camera control button. The button appears when the user hovers over the Picture-in-Picture window.">
Turn on camera
</message>
<message name="IDS_PICTURE_IN_PICTURE_TURN_OFF_CAMERA_TEXT" desc="Text label of the turn off camera control button. The button appears when the user hovers over the Picture-in-Picture window.">
Turn off camera
</message>
<message name="IDS_PICTURE_IN_PICTURE_HANG_UP_TEXT" desc="Text label of the hang up control button. The button appears when the user hovers over the Picture-in-Picture window.">
Hang up
</message>
<message name="IDS_PICTURE_IN_PICTURE_CLOSE_CONTROL_TEXT" desc="Text label of the close control button. The button appears when the user hovers over the Picture-in-Picture window.">
Close
</message>
<message name="IDS_PICTURE_IN_PICTURE_RESIZE_HANDLE_TEXT" desc="Text label of the resize handle. The button appears when the user hovers over the Picture-in-Picture window.">
Resize
</message>
<message name="IDS_PICTURE_IN_PICTURE_PLAY_PAUSE_CONTROL_ACCESSIBLE_TEXT" desc="Accessible text label used for the controls button in the Picture-in-Picture window. The button toggles between play and pause controls.">
Toggle video to play or pause
</message>
<message name="IDS_PICTURE_IN_PICTURE_MUTE_CONTROL_ACCESSIBLE_TEXT" desc="Accessible text label used for the controls button in the Picture-in-Picture window. The button toggles mute state.">
Toggle mute
</message>
<message name="IDS_PICTURE_IN_PICTURE_NEXT_TRACK_CONTROL_ACCESSIBLE_TEXT" desc="Accessible text label used for the controls button in the Picture-in-Picture window. The button invokes next track action.">
Next track
</message>
<message name="IDS_PICTURE_IN_PICTURE_PREVIOUS_TRACK_CONTROL_ACCESSIBLE_TEXT" desc="Accessible text label used for the controls button in the Picture-in-Picture window. The button invokes previous track action.">
<message name="IDS_UTILITY_PROCESS_UTILITY_WIN_NAME" desc="The name of the utility process used to handle Windows utility operations.">
Windows Utilities
</message>
</if>
<message name="IDS_DOWNLOAD_MORE_ACTIONS"
desc="Tooltip of a button on the downloads page that shows a menu with actions like 'Open downloads folder' or 'Clear all'">
More actions
</message>
<!-- Badging -->
<message name="IDS_SATURATED_BADGE_CONTENT" desc="The content to display when the application's badge is too large to display to indicate that the badge is more than a given maximum. This string should be as short as possible, preferably only one character beyond the content">
<ph name="MAXIMUM_VALUE">$1<ex>99</ex></ph>+
</message>
<message name="IDS_BADGE_UNREAD_NOTIFICATIONS_SATURATED" desc="The accessibility text which will be read by a screen reader when the notification count is too large to display (e.g. greater than 99).">
{MAX_UNREAD_NOTIFICATIONS, plural, =1 {More than 1 unread notification} other {More than # unread notifications}}
</message>
<message name="IDS_BADGE_UNREAD_NOTIFICATIONS_UNSPECIFIED" desc="The accessibility text which will be read by a screen reader when there are some unspecified number of notifications, or user attention is required">
Unread Notifications
</message>
<message name="IDS_BADGE_UNREAD_NOTIFICATIONS" desc="The accessibility text which will be read by a screen reader when there are notifcatications">
{UNREAD_NOTIFICATIONS, plural, =1 {1 Unread Notification} other {# Unread Notifications}}
</message>
<message name="IDS_HID_CHOOSER_ITEM_WITHOUT_NAME" desc="User option displaying the device IDs for a Human Interface Device (HID) without a device name.">
<message name="IDS_AX_UNLABELED_IMAGE_ROLE_DESCRIPTION" desc="Accessibility role description for a graphic (image) on a web page or PDF that does not have a description for blind users." is_accessibility_with_no_ui="true">
Unlabeled graphic
</message>
</then>
<else>
<message name="IDS_AX_UNLABELED_IMAGE_ROLE_DESCRIPTION" desc="Accessibility role description for an image on a web page or PDF that does not have a description for blind users." is_accessibility_with_no_ui="true">
deprecate.log('The default sandbox option for windows without nodeIntegration is changing. Presently, by default, when a window has a preload script, it defaults to being unsandboxed. In Electron 20, this default will be changing, and all windows that have nodeIntegration: false (which is the default) will be sandboxed by default. If your preload script doesn\'t use Node, no action is needed. If your preload script does use Node, either refactor it to move Node usage to the main process, or specify sandbox: false in your WebPreferences.');
}
// Read off the ID at construction time, so that it's accessible even after
@@ -658,14 +668,15 @@ WebContents.prototype._init = function () {
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.
